<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>http on Natenoms Blog</title><link>https://natenom.de/tags/http/</link><description>Recent content in http on Natenoms Blog</description><generator>Hugo -- gohugo.io</generator><language>de</language><copyright/><lastBuildDate>Sat, 19 Dec 2015 20:35:58 +0000</lastBuildDate><atom:link href="https://natenom.de/tags/http/index.xml" rel="self" type="application/rss+xml"/><item><title>Nur noch HTTPS für meine Webseiten :)</title><link>https://natenom.de/2015/12/nur-noch-https-fuer-meine-webseiten/</link><pubDate>Sat, 19 Dec 2015 20:35:58 +0000</pubDate><guid>https://natenom.de/2015/12/nur-noch-https-fuer-meine-webseiten/</guid><description>&lt;p>Seit ich &lt;a href="/2015/11/https-for-natenoms-websites-thanks-letsencrypt-d/">valide Letsencrypt-Zertifikate&lt;/a> nutzen kann, habe ich meine Webseiten so umgestellt, dass die Links fast überall auf https:// zeigen. http:// war zwar weiterhin verfügbar, wurde aber kaum noch genutzt.&lt;/p></description><content:encoded><![CDATA[<p>Seit ich <a  href="/2015/11/https-for-natenoms-websites-thanks-letsencrypt-d/">valide Letsencrypt-Zertifikate</a> nutzen kann, habe ich meine Webseiten so umgestellt, dass die Links fast überall auf https:// zeigen. http:// war zwar weiterhin verfügbar, wurde aber kaum noch genutzt.</p>
<p>Seit heute wird jeglicher Traffic von http:// auf https:// umgeleitet; aktuell noch per Status-Code 302, später dann per 301.</p>
<p>Habe dafür in den letzten Tagen alle internen Verlinkungen z. B. hier im Blog auch auf https umgestellt, so wie auch in meinen beiden Wikis.</p>
<p>Hatte schon länger vor das umzusetzen und da kam <a  class='urlextern'  href="https://googleonlinesecurity.blogspot.de/2015/12/indexing-https-pages-by-default.html">dieser Artikel</a> heute als Erinnerung daran gerade recht :)</p>]]></content:encoded></item><item><title>WordPress verlinkt Bilder per HTTPS auch wenn HTTP eingestellt ist… (?)</title><link>https://natenom.de/2015/04/wordpress-verlinkt-bilder-per-https-auch-wenn-http-eingestellt-ist/</link><pubDate>Tue, 28 Apr 2015 20:58:48 +0000</pubDate><guid>https://natenom.de/2015/04/wordpress-verlinkt-bilder-per-https-auch-wenn-http-eingestellt-ist/</guid><description>&lt;p>Habe heute erst bemerkt, dass (?nur mein?) WordPress neuerdings beim Einfügen von Bildern im Editor diese immer per https verlinkt, was hier im Blog aufgrund eines &lt;a href="https://wiki.natenom.de/docs/sammelsurium/selbst-signierte-zertifikate">selbst signierten Zertifikates&lt;/a> dazu geführt hat, dass vermutlich bei den meisten Besuchern statt der Bilder nur die URLs angezeigt wurden.&lt;/p></description><content:encoded><![CDATA[<p>Habe heute erst bemerkt, dass (?nur mein?) WordPress neuerdings beim Einfügen von Bildern im Editor diese immer per https verlinkt, was hier im Blog aufgrund eines <a  href="https://wiki.natenom.de/docs/sammelsurium/selbst-signierte-zertifikate">selbst signierten Zertifikates</a> dazu geführt hat, dass vermutlich bei den meisten Besuchern statt der Bilder nur die URLs angezeigt wurden.</p>
<p>Unter „Einstellungen“ -&gt; „Allgemein“ sind sowohl „WordPress-Adresse (URL)“ als auch „Website-Adresse (URL)“ auf http eingestellt und dadurch sollte eigentlich auch im gesamten Blog alles nur per HTTP eingebunden werden; dies hat in der Vergangenheit auch funktioniert.</p>
<p>Menschen, die auch einen Blog mit selbst signiertem Zertifikat betreiben, können das ja mal im eigenen Blog überprüfen.</p>
<p>Ich weiss nicht genau, ob das erst seit dem Update auf 4.2 so ist oder schon länger.</p>

<h2 id="alte-artikel-korrigieren" data-numberify>Alte Artikel korrigieren<a class="anchor ms-1" href="#alte-artikel-korrigieren"></a></h2>
<p>Um die Bilder in allen bisherigen Beiträge von https auf http umzustellen, habe ich das WordPress Plugin <a  href="/2014/03/wordpress-selbst-eingefuegte-weiterlesen-links-in-allen-artikeln-mit-hilfe-von-search-regex-deaktivieren/">Search Regex</a> verwendet und damit die Strings „/wp-content/uploads/“ durch „/wp-content/uploads/“ ersetzen lassen:</p>
<p><a  href="/wp-content/uploads/2015/04/wordpress_search-regex-example_http_https.png"><img loading="lazy" class="alignnone size-large wp-image-32099" src="/wp-content/uploads/2015/04/wordpress_search-regex-example_http_https-600x422.png" alt="wordpress_search-regex-example_http_https" srcset="/wp-content/uploads/2015/04/wordpress_search-regex-example_http_https-600x422.png 600w, /wp-content/uploads/2015/04/wordpress_search-regex-example_http_https-150x105.png 150w, /wp-content/uploads/2015/04/wordpress_search-regex-example_http_https-300x211.png 300w, /wp-content/uploads/2015/04/wordpress_search-regex-example_http_https.png 821w" sizes="(max-width: 474px) 100vw, 474px" /></a></p>

<h2 id="problem-insgesamt-beheben" data-numberify>Problem insgesamt beheben?<a class="anchor ms-1" href="#problem-insgesamt-beheben"></a></h2>
<p>Eine Lösung für das Problem konnte ich bisher leider nicht finden und ein kostenpflichtiges SSL-Zertifikat ist mir viel zu teuer. Auch kenne ich mich mit WordPress nicht wirklich aus, um das Problem zu lokalisieren.</p>
<p>Deshalb begnüge ich mich zunächst damit, nach dem Erstellen eines Artikels mit dem oben genannten Plugin alle neuen URLs von Grafiken mit http zu ersetzen.</p>
<p>Melde mich, wenn es was Neues diesbezüglich gibt. Vielleicht weiss ja jemand, wie man das lösen kann :)</p>
<p><span style="text-decoration: underline;"><span style="color: #ff0000; text-decoration: underline;">Update vom 11.05.2015:</span></span><br>
<span style="color: #ff0000;">Es gab in der Zwischenzeit zwei Sicherheitsupdates für WordPress und heute gerade ist mir aufgefallen, dass das Problem nicht mehr auftritt.</span></p>]]></content:encoded></item><item><title>Weiterleitungen testen mit cURL</title><link>https://natenom.de/2013/01/weiterleitungen-testen-mit-curl/</link><pubDate>Fri, 18 Jan 2013 08:21:13 +0000</pubDate><guid>https://natenom.de/2013/01/weiterleitungen-testen-mit-curl/</guid><description>Wenn man öfters mal http-Weiterleitungen testet, bietet sich cURL an, da es die Ergebnisse nicht zwischenspeichert, wie z. B. Browser (bei denen der Weiterleitungscache teils nur umständlich löschbar ist).
Hier die gekürzte Ausgabe von cURL am Beispiel von natenom.com/r/getmumble/dev/win, welches immer auf den Download der aktuellen Entwicklerversion von Mumble verlinkt:
curl -v -s natenom.com/r/getmumble/dev/win […]
&amp;lt; HTTP/1.1 302 Found
&amp;lt; Date: Fri, 18 Jan 2013 02:09:13 GMT &amp;lt; Server: Apache</description><content:encoded><![CDATA[<p>Wenn man öfters mal http-Weiterleitungen testet, bietet sich <a title="http://curl.haxx.se/" href="http://curl.haxx.se/" target="_self">cURL</a> an, da es die Ergebnisse nicht zwischenspeichert, wie z. B. Browser (bei denen der Weiterleitungscache teils nur umständlich löschbar ist).</p>
<p>Hier die gekürzte Ausgabe von cURL am Beispiel von <del>natenom.com/r/getmumble/dev/win</del>, welches immer auf den Download der aktuellen Entwicklerversion von Mumble verlinkt:</p>
<blockquote>
<p>curl -v -s natenom.com/r/getmumble/dev/win
[…]<br>
&lt; HTTP/1.1 302 Found<br>
&lt; Date: Fri, 18 Jan 2013 02:09:13 GMT
&lt; Server: Apache<br>
&lt; Location: <a  class='urlextern'  href="http://mumble.info/snapshot/mumble-1.2.4-rc1-1-g8cbf176.msi">http://mumble.info/snapshot/mumble-1.2.4-rc1-1-g8cbf176.msi</a><br>
[…]</p>
</blockquote>
]]></content:encoded></item></channel></rss>