Er kan een "http"-fout optreden. Veel mensen beginnen dan hun situatie te analyseren laatste acties, geproduceerd in WordPress, maar de meeste mensen hebben simpelweg geen idee wat er is gebeurd, omdat er niets “slechts” leek te zijn gedaan. Als je naar de antwoorden op internet kijkt op de vraag "waarom geeft het een http-fout bij het laden van afbeeldingen", kun je verschillende aanbevelingen vinden die deze fout kunnen elimineren.

Aanbevelingen om de fout op te lossen bij het downloaden van afbeeldingen "http"

De eerste aanbeveling is om de hele lijst te doorzoeken geïnstalleerde plug-ins en schakel alle overbodige uit. U moet ook alle plug-ins uitschakelen en één voor één inschakelen, en vervolgens het effect van hun werk op uw site bekijken. Het uploaden van foto's kan dus werken, maar het is verre van zeker dat u precies de plug-in kunt detecteren die de fout veroorzaakt. Als je tijd en geduld hebt, probeer dan deze aanbeveling, maar we vonden het te lastig, dus we hebben deze optie in reserve gehouden.

De tweede aanbeveling stelt dat het hele probleem mogelijk ligt in de server waarop uw site zich bevindt. Maar als je andere sites hebt die met deze host werken, en alles is goed met hen in perfecte staat, wat betekent dat de fout ergens op de site zelf ligt. Als er maar één site is, neem dan contact op met de host, voor het geval het probleem daar echt ligt.

Hierbij merken we ook op dat het niet altijd rationeel is om te updaten naar een versie die net is uitgebracht.

In de regel bevat het veel nuttige innovaties/updates, maar niet alle plugin-ontwikkelaars hebben tijd om aanpassingen aan hun producten door te voeren. Dat wil zeggen, als alles nu goed met je gaat, heeft het geen zin om je te haasten om de motor bij te werken.

De vierde tip is om de volgende code toe te voegen aan het .htaccess-bestand:

SecFilterEngine Uit
SecFilterScanPOST Uit

Bovenstaande code moet aan het einde of begin van het bestand worden geplaatst, waarna alles kan werken.
De volgende tip is om de code in het .htaccess-bestand in te voegen met behulp van een FTP-uploader:

SecFilterEngine Uit
SecFilterScanPOST Uit

Houd er rekening mee dat als u al een dergelijke code in het bestand heeft, u deze moet herschrijven, dat wil zeggen vervangen door een nieuwe. Probeer nu het mediabestand te downloaden; Bovendien kunt u bestanden in onbeperkte hoeveelheden uploaden. We hebben herhaaldelijk gemerkt dat in één geval alles zal werken als je de code aan het begin van het bestand plakt; bij het plakken van de code op een andere site aan het begin van het bestand werkte niets, maar alles begon te werken zodra de code naar het einde van het bestand werd verplaatst.

Houd er rekening mee dat dit bestand na het updaten van WordPress gemakkelijk kan worden overschreven en dat de fout opnieuw kan optreden. Om dit te voorkomen, raden wij u aan een back-upbestand op uw computer op te slaan en, als er iets gebeurt, dit via FTP naar de server te uploaden.

Een andere aanbeveling is om de WPupload-plug-in te installeren, die de standaard WordPress-uploader vervangt door een nieuwe (deze ondersteunt HTML5, Flash, BrowserPlus, enz.). Echter, nieuwe plug-in kan nieuwe problemen aan de site toevoegen, maar het zal in ieder geval deze fout elimineren bij het laden van “http”-afbeeldingen.

Uit al het bovenstaande volgt een eenvoudige conclusie: als u wilt dat uw site stabiel werkt, haast u dan niet met . Een nieuwe versie hoewel het belooft functioneler en veiliger te zijn, is het dat wel externe ontwikkelaars Ze hebben niet altijd de tijd om hun producten te optimaliseren voor nieuwe versies (dit is de reden waarom de ‘http’-fout kan verschijnen).

Soms ontstaan ​​er situaties waarbij een webbrowser een foutmelding geeft bij het opvragen van een site. Dergelijke fouten hebben digitale code en een specifieke beschrijving.

(101-199) Informatieve antwoorden

Dergelijke reacties geven aan dat een verzoek van een bepaalde klant is geaccepteerd en direct wordt verwerkt.

• 100 - Doorgaan - het eerste deel van het verzoek is geaccepteerd, de klant kan het blijven verzenden.
• 101 - Switching Protocols - de service voldoet aan bepaalde clientvereisten en schakelt ook tussen protocollen, wat overeenkomt met de gegevens in het veld Upgrade-header.

(200-299) Succesvolle verzoeken cliënt

In dit bereik worden alle klantverzoeken met succes voltooid.

• 200 - OK - succesvolle verwerking van het clientverzoek en het serverantwoord bevat alle gevraagde gegevens.
• 201 - Aangemaakt - deze statuscode kan worden gebruikt bij het wijzigen van de URL. Naast de code geeft de server ook een Location-header uit, die alle informatie bevat over de locatie van alle nieuwe gegevens die worden verplaatst.
• 202 - Geaccepteerd - het verzoek wordt geaccepteerd, maar wordt niet onmiddellijk verwerkt. De inhoud van het antwoord kan ook bepaalde informatie over de transactie bevatten. Er is geen garantie dat een verzoek wordt ingewilligd, ook al was het geldig op het moment van toelating.
• 203 - Niet-geautoriseerde informatie - De inhoudskop bevat informatie die is verkregen van een lokale kopie of van een derde partij.
• 204 - Geen inhoud - het antwoord bevat alleen een header en statuscode, de antwoordtekst zelf wordt niet gegeven. Wanneer een dergelijk antwoord wordt ontvangen, mag het browserdocument niet worden vernieuwd. De code kan terugkeren nadat de gebruiker op lege delen van de afbeelding heeft geklikt.
• 205 - Inhoud resetten - het formulier dat wordt gebruikt voor aanvullende invoergegevens wordt door de browser gewist.
• 206 - Gedeeltelijke inhoud - de server retourneert slechts een deel van de gegevens. Wordt gebruikt in een verzoekantwoord bij het opgeven van een Range-header. De server moet dit aangeven in de Content-Range-header bepaald bereik, dat is opgenomen in het antwoord.

(300-399) Doorsturen

Een responscode in dit bereik betekent dat de client bepaalde acties moet uitvoeren om aan het verzoek te voldoen.

• 300 - Meerdere keuzes (meerdere opties om uit te kiezen) - de gevraagde URL kan verschillende bronnen bevatten. De inhoudstekst die door de server wordt geretourneerd, moet bepaalde informatie bevatten over het maken van de juiste keuze bron.
• 301 - Permanent verplaatst (bron verplaatst naar permanente basis) - de server gebruikt niet langer de vereiste URL, daarom wordt de in het verzoek gespecificeerde bewerking niet uitgevoerd. De kop Locatie geeft informatie over de nieuwe locatie van het opgevraagde document. Volgende verzoeken moeten de nieuwe URL specificeren.
• 302 - Tijdelijk verplaatst (bron is tijdelijk verplaatst) - tijdelijke verplaatsing van de opgevraagde URL. De kop Locatie geeft de nieuwe locatie aan. Na ontvangst van de statuscode moet de client het verzoek oplossen via de nieuwe URL, maar dan alleen de oude gebruiken.
• 303 - Zie Overige (zie een andere bron) - het zoeken naar de gevraagde URL wordt uitgevoerd door een andere URL op te geven, die zich in de Locatie-header bevindt.
• 304 - Niet gewijzigd - is de responscode voor de header lf-Modified-Since als de URL niet is gewijzigd. De inhoudstekst is niet aanwezig, dus de client moet er een lokale kopie van gebruiken.
• 305 - Gebruik proxy (gebruik een proxyserver) - de gevraagde bron moet toegankelijk zijn via een proxyserver, die is opgegeven in het veld Locatie. Dit veld bevat ook de URL van de vereiste proxyserver. Het verzoek moet worden herhaald aan de ontvanger.

(400-499) Onvolledige klantverzoeken

Antwoordcodes in dit bereik geven aan dat het verzoek van de klant onvolledig is. Het kan ook betekenen dat de klant aanvullende gegevens moet invoeren.

• 400 - Foute aanvraag(onjuist verzoek) - de server begrijpt het verzoek niet vanwege de verkeerd opgemaakte syntaxis. Het verzoek kan worden herhaald, maar alleen nadat bepaalde wijzigingen zijn aangebracht.
• 401 - Ongeautoriseerd (geen toestemming) - de gebruiker moet zijn authenticiteit bevestigen. Het antwoord moet een WWW-Authenticate-headerveld bevatten met een uitdaging die van toepassing is op de aangevraagde bron. Het verzoek kan worden herhaald, maar met een geschikt headerveld Autorisatie. Als dit veld al authenticatie-aanbevelingen bevat, geeft een 401-statuscode aan dat dergelijke aanbevelingen niet geschikt zijn voor authenticatie.
• 402 - Betaling vereist - De code is gereserveerd en zal in de toekomst worden gebruikt, maar is nog niet geïmplementeerd in HTTP.
• 403 - Verboden (toegang geweigerd) - het verzoek is afgewezen, dus de server kan niet op de client reageren.
• 404 - Niet gevonden(bron niet gevonden) - de opgegeven URL bestaat niet meer Vereist document, dat wil zeggen dat de server niets heeft gevonden dat aan dit verzoek kan voldoen.
• 405 - Methode niet toegestaan ​​- De header Allow geeft aan dat de door de client gebruikte methode niet wordt ondersteund.
• 406 - Niet acceptabel - De geïdentificeerde bron kan alleen objecten genereren met een inhoudskenmerk dat niet overeenkomt met de acceptatieheaders.
• 407 - Proxy-authenticatie vereist (registratie bij de proxyserver is vereist) - geeft aan dat de client moet worden geverifieerd bij de proxyserver. De proxyserver retourneert een Proxy-Authenticate-headerveld met de specifieke uitdaging. Het verzoek kan worden herhaald, maar alleen als een geschikt headerveld is opgegeven.
• 408 - Time-out van verzoek (verwerkingstijd van verzoek is verstreken) - het verzoek is niet voltooid door de client terwijl de server aan het wachten was. Het verzoek kan later worden herhaald.
• 409 - Conflict - De aanvraag kan niet worden verwerkt omdat er een conflict is met de status van de bron. Van de gebruiker wordt verwacht dat hij het conflict oplost en de aanvraag opnieuw indient.
• 410 - Verdwenen (bron bestaat niet meer) - de gevraagde URL is niet langer beschikbaar op de server.
• 411 - Lengte vereist (lengte moet worden opgegeven) - het verzoek wordt niet geaccepteerd door de server omdat de inhoudslengte niet is gedefinieerd. Het verzoek kan worden herhaald door de lengte van de berichttekst op te geven in het headerveld Content-Length.
• 412 - Voorwaarde mislukt - Het verzoek wordt niet door de server verwerkt omdat het verzoekobject veel groter is dan het kan verwerken. In deze situatie is het mogelijk om de verbinding te verbreken. Als deze toestand tijdelijk is, specificeert de server een tijdstip in de Retry-After-header waarna de client het opnieuw kan proberen.
• 413 - Request Entity Too Large (het aangevraagde element is te groot) - het verzoek wordt niet verwerkt door de server vanwege de enorme omvang ervan.
• 414 - Request-URI Too Long (de bron-ID in het verzoek is te lang) - het verzoek wordt niet verwerkt door de server omdat de URL vrij lang is.
• 415 - Niet-ondersteund mediatype (niet-ondersteund apparaattype) - de server weigerde het verzoek te verwerken omdat de aangevraagde bron het formaat van het verzoekobject niet ondersteunt.

(500-599) Serverfouten

Dit bereik geeft aan dat het verzoek hoogstwaarschijnlijk zal mislukken omdat de server een specifieke fout heeft aangetroffen.

• 500 - Intern Serverfout (Interne fout server) - Tijdens het verwerken van een verzoek heeft een van de servercomponenten een specifieke configuratiefout aangetroffen.
• 501 - Niet geïmplementeerd (functie niet geïmplementeerd) - het clientverzoek kan niet worden vervuld omdat het verzoek voor sommigen ondersteuning vereist functionaliteit. Kan worden uitgegeven wanneer de server de verzoekmethode niet kan herkennen.
• 502 - Slechte gateway(gatewaydefect) - de server ontving, toen hij als proxyserver werkte, een ongeldig antwoord in de verzoekketen van de volgende server.
• 503 - Service niet beschikbaar - De service is tijdelijk niet beschikbaar, maar de toegang kan na een tijdje worden hervat. Als de server over bepaalde gegevens beschikt, kan deze een antwoord geven met de Retry-After-header.
• 504 - Gateway Timeout (de tijd die door de gateway is gegaan is verstreken) - de gateway of server heeft de tijdslimiet overschreden.
• 505 - HTTP-versie niet ondersteund ( niet-ondersteunde versie HTTP) - versie niet ondersteund door de server HTTP-protocol, die in het verzoek is gebruikt.

HTTP-( HyperText-overdracht Protocol - Hypertext Transfer Protocol) werd als basis ontwikkeld Wereldwijd Web.

Het HTTP-protocol werkt als volgt: het clientprogramma brengt een TCP-verbinding tot stand met de server ( Standaard kamer port-80) en verzendt er een HTTP-verzoek naar. De server verwerkt dit verzoek en geeft een HTTP-antwoord aan de client.

HTTP-verzoekstructuur

Een HTTP-verzoek bestaat uit een verzoekheader en een verzoektekst, gescheiden door een lege regel. De aanvraagtekst ontbreekt mogelijk.

De verzoekheader bestaat uit de hoofdregel (eerste regel) van het verzoek en daaropvolgende regels die het verzoek in de hoofdregel verduidelijken. Ook volgende regels kunnen ontbreken.

De hoofdregelquery bestaat uit drie delen, gescheiden door spaties:

Methode(met andere woorden, het HTTP-commando):

KRIJGEN- documentaanvraag. De meest gebruikte methode; in HTTP/0.9, zeggen ze, was hij de enige.

HOOFD- verzoek om documenttitel. Het verschilt van GET doordat alleen de verzoekheader met informatie over het document wordt geretourneerd. Het document zelf wordt niet afgegeven.

NA- deze methode wordt gebruikt om gegevens over te dragen naar CGI-scripts. De gegevens zelf verschijnen in de volgende regels van het verzoek in de vorm van parameters.

NEERZETTEN- plaats het document op de server. Voor zover ik weet wordt het zelden gebruikt. Een verzoek met deze methode heeft een body waarin het document zelf wordt verzonden.

Bron- dit is de manier om specifiek bestand op de server die de client wil ontvangen (of plaatsen - voor de PUT-methode). Als de bron eenvoudigweg een bestand is dat moet worden gelezen, moet de server dit voor dit verzoek in de antwoordtekst retourneren. Als dit het pad naar een CGI-script is, voert de server het script uit en retourneert het resultaat van de uitvoering ervan. Trouwens, dankzij deze unificatie van bronnen is de klant praktisch onverschillig voor wat hij op de server vertegenwoordigt.

Protocolversie-versie van het HTTP-protocol waarmee het clientprogramma werkt.

Een eenvoudig HTTP-verzoek zou er dus als volgt uit kunnen zien:

Hiermee wordt het rootbestand opgevraagd uit de hoofdmap van de webserver.

De regels na de hoofdqueryregel hebben het volgende formaat:

Parameter: waarde.

Dit is hoe de aanvraagparameters worden ingesteld. Dit is optioneel; alle regels na de hoofdqueryregel ontbreken mogelijk; in dit geval accepteert de server de waarde ervan standaard of op basis van de resultaten van het vorige verzoek (wanneer in de Keep-Alive-modus wordt gewerkt).

Ik zal enkele van de meest gebruikte HTTP-verzoekparameters opsommen:

Verbinding(verbinding) - kan de waarden Keep-Alive en close aannemen. Keep-Alive betekent dat na uitgifte van dit document de verbinding met de server niet wordt verbroken en er meer verzoeken kunnen worden gedaan. De meeste browsers werken in de Keep-Alive-modus, omdat u hiermee een HTML-pagina en afbeeldingen ervoor kunt "downloaden" in één verbinding met de server. Eenmaal ingesteld, wordt de Keep-Alive-modus gehandhaafd tot de eerste fout of tot de volgende verbinding: het sluitverzoek wordt expliciet gespecificeerd.
close ("close") - de verbinding wordt gesloten nadat op dit verzoek is gereageerd.

Gebruiker-agent- de waarde is de "code" van de browser, bijvoorbeeld:

Mozilla/4.0 (compatibel; MSIE 5.0; Windows 95; DigExt)

Aanvaarden- een lijst met inhoudstypen die door de browser worden ondersteund, in volgorde van hun voorkeur voor een bepaalde browser, bijvoorbeeld voor mijn IE5:

Accepteren: afbeelding/gif, afbeelding/x-xbitmap, afbeelding/jpeg, afbeelding/pjpeg, applicatie/vnd.ms-excel, applicatie/msword, applicatie/vnd.ms-powerpoint, */*

Dit is uiteraard nodig als de server hetzelfde document in verschillende formaten kan uitvoeren.

De waarde van deze parameter wordt voornamelijk door CGI-scripts gebruikt om een ​​antwoord te genereren dat is aangepast voor een bepaalde browser.

Verwijzer- URL van waaruit u naar deze bron bent gekomen.

Gastheer- de naam van de host waarvan de bron wordt aangevraagd. Handig als de server meerdere virtuele servers onder hetzelfde IP-adres heeft. In dit geval de naam virtuele server bepaald door dit veld.

Accepteren-Taal- ondersteunde taal. Belangrijk voor een server die hetzelfde document in verschillende taalversies kan aanbieden.

HTTP-antwoordformaat

Het antwoordformaat lijkt sterk op het verzoekformaat: het heeft ook een header en body, gescheiden door een lege regel.

De header bestaat ook uit een hoofdregel en parameterregels, maar het formaat van de hoofdregel is anders dan die van de request-header.

De hoofdqueryreeks bestaat uit 3 velden, gescheiden door spaties:

Protocolversie- vergelijkbaar met de overeenkomstige verzoekparameter.

Foutcode- codeaanduiding van het “succes” van het verzoek. Code 200 betekent "alles is normaal" (OK).

Mondelinge beschrijving van de fout- het “ontcijferen” van de vorige code. Voor 200 is het bijvoorbeeld OK, voor 500 - Interne server Fout.

De meest voorkomende http-responsparameters:

Verbinding- vergelijkbaar met de overeenkomstige verzoekparameter.
Als de server Keep-Alive niet ondersteunt (er zijn er enkele), dan is de verbindingswaarde in het antwoord altijd dichtbij.

Daarom is naar mijn mening de juiste browsertactiek de volgende:
1. geef Connection: Keep-Alive op in het verzoek;
2. De verbindingsstatus kan worden beoordeeld aan de hand van het veld Verbinding in het antwoord.

Inhoudstype(“inhoudstype”) - bevat een aanduiding van het inhoudstype van het antwoord.

Afhankelijk van de Content-Type-waarde interpreteert de browser het antwoord als een HTML-pagina, gif-afbeelding of jpeg, als een bestand dat op schijf moet worden opgeslagen, of wat dan ook, en onderneemt passende actie. De Content-Type-waarde voor de browser is hetzelfde als de bestandsextensiewaarde voor Windows.

Enkele inhoudstypen:

tekst/html - tekst in HTML-formaat (webpagina);
tekst/plain - platte tekst (vergelijkbaar met Kladblok);
afbeelding/jpeg - afbeelding in JPEG-formaat;
afbeelding/gif - hetzelfde, in GIF-formaat;
application/octet-stream - een stroom "octetten" (dat wil zeggen alleen bytes) om naar schijf te schrijven.

Er zijn eigenlijk nog veel meer soorten inhoud.

Inhoud lengte("inhoudslengte") - de lengte van de antwoordinhoud in bytes.

Laatst gewijzigd("Gewijzigd naar laatste keer") - datum laatste wijziging document.

In verband met de massale transitie van sites naar HTTPS werden ontwikkelaars en sitebeheerders geconfronteerd met een aantal nieuwe problemen. Eén daarvan is een omleiding van HTTP naar HTTPS en de noodzaak om omleidingen naar het canonieke siteadres op de juiste manier af te handelen om dubbele inhoud te voorkomen.

HTTPS en omleidingen

Laten we eens kijken naar een voorbeeld. Laten we zeggen dat we een website dnsimple.com hebben. Het is canoniek URL - https://dnsimple.com. Er zijn er echter vier verschillende manieren, waarmee u verbinding kunt maken met de site, en u moet ervoor zorgen dat de gebruiker bij elk van deze wordt doorgestuurd naar https://dnsimple.com:

Het configureren van htaccess-omleidingen van HTTP naar HTTPS is vaak een bron van verwarring. Het is niet altijd duidelijk hoe omleidingen van WWW naar niet-WWW (of vice versa) via HTTPS correct moeten worden afgehandeld, en waarom dit SSL-certificaat/TLS. Om deze omleidingen correct te configureren, moet u de basisprincipes van de verwerking van HTTPS-verzoeken begrijpen.

Vervolgens kijken we naar de volgorde waarin een verbinding tot stand komt via het HTTPS-protocol, hoe HTTP-verzoeken worden verwerkt en het opzetten van redirects met HTTPS-ondersteuning.

HTTPS-verzoekstroom

De afbeelding hierboven toont het HTTPS-verzoek/antwoordstroomdiagram. Voor de eenvoud hebben we alle acties in drie fasen verdeeld:

1. In de eerste fase komen de client en de server tot overeenstemming over de encryptiedetails, zoals het encryptieprotocol en de coderingssuite. De gegevens die nodig zijn om over te schakelen naar een beveiligde verbinding komen ook voor: openbare sleutels, certificaatinformatie, enz. Deze fase heet ‘ SSL/TLS-handshake»;
2. In de tweede fase bereidt de client een HTTP-verzoek voor, codeert dit en stuurt het ter verwerking naar de server. De server ontvangt een gecodeerd HTTP-verzoek, decodeert dit, verwerkt het en geeft een HTTP-antwoord (response);
3. In de derde fase codeert de server het antwoord en stuurt het ter verwerking naar de client. De client ontvangt een gecodeerd HTTP-antwoord, decodeert en verwerkt dit ( De browser begint bijvoorbeeld elementen te laden en weer te geven).

Dit HTTP-naar-HTTPS-omleidingsstroomdiagram is van toepassing op elk verzoek, ongeacht de inhoud van het HTTP-antwoord.

Hierboven schreef ik HTTP-verzoek en HTTP-reactie voor bepaalde doeleinden ( merk op dat ik HTTP heb gebruikt en niet HTTPS). Qua inhoud en structuur is het belangrijk om te begrijpen dat een HTTPS-verzoek een HTTP-verzoek is, maar verzonden via een beveiligde verbinding ( TLS/SSL).

HTTPS-onderhandelingen en omleidingen

Een van de meest voorkomende fouten bij het instellen van HTTPS-omleidingen is dat je ervan uitgaat dat je geen SSL-certificaat nodig hebt als je een client van het ene domein naar het andere omleidt.

Als u naar de aanvraagstroom kijkt, ziet u dat de uitwisseling van SSL-certificaten en de onderhandelingen over encryptie in de eerste fase worden uitgevoerd. Houd er rekening mee dat de server in dit stadium geen idee heeft welke pagina de client nodig heeft: de client en de server beslissen hoe ze met elkaar communiceren.

Na voltooiing van de eerste fase, wanneer de client en server het hebben gevonden onderlinge taal (encryptieprotocol), kunnen ze met elkaar communiceren via een gecodeerde verbinding. Op dit punt verzendt de client een HTTP-verzoek naar de server, en de server verzendt een HTTP-antwoord met daarin de omleiding.

Vergeet niet dat een redirect een HTTP-antwoord is met een 301-code (soms 302 of 307):

HTTP/1.1 301 Permanent verplaatst Server: nginx Datum: ma, 01 aug 2016 14:41:25 GMT Locatie: https://dnsimple.com/

Voordat u een omleiding van HTTPS naar HTTP maakt, moet u er rekening mee houden dat als u een omleiding voor het hele domein moet maken, u een geldig SSL-certificaat nodig heeft voor het omgeleide domein. Voor versleutelingsonderhandelingen is een SSL-certificaat vereist en dit vindt plaats voordat het verzoek is verwerkt en het omleidingsantwoord is teruggestuurd naar de client.

Als het anders was gegaan, zou de redirect zijn verwerkt voordat het SSL-certificaat werd gecontroleerd. De client en server zouden dan gedwongen worden om te communiceren via een reguliere HTTP-verbinding, die niet gecodeerd is.

Als u een client van een pagina in het domein https://www.example.com naar een andere pagina moet omleiden, heeft u een geldig SSL-certificaat nodig dat op de server is geïnstalleerd en dat van toepassing is op het hele domein www.example.com.

Als u bijvoorbeeld een client wilt omleiden van https://www.example.com naar https://example.com, moet u over een certificaat beschikken dat beide of twee afzonderlijke certificaten dekt ( voor elke gastheer respectievelijk).

HTTPS-omleidingsstrategieën

We hebben gekeken hoe een redirect van HTTP naar HTTPS via htaccess wordt verwerkt na SSL/TLS-onderhandeling. We kwamen er ook achter dat om klanten van een site of pagina naar HTTPS te kunnen omleiden, je een geldig SSL-certificaat nodig hebt dat beide domeinen dekt. Vervolgens zal ik het hebben over algemene strategieën Instellingen voor HTTPS-omleiding.

Er zijn twee manieren om omleidingen met HTTPS in te stellen:

1. Omleiden op serverniveau;
2. Omleiding op applicatieniveau.

De term server verwijst naar elke server die voor een webapplicatie staat en een binnenkomend HTTP-verzoek verwerkt. Bijvoorbeeld een front-end server, een load-balancing server of een enkele applicatie.

De term applicatie duidt een webapplicatie aan, die zo eenvoudig kan zijn als een PHP-script of complexer, zoals een Unicorn-applicatie aan de serverzijde die Ruby on Rails interpreteert.

HTTPS-omleidingen uitvoeren op serverniveau

Het verdient de voorkeur om HTTPS-omleidingen op serverniveau uit te voeren. In dit geval accepteert de server waarop het SSL-certificaat is geïnstalleerd het gecodeerde HTTP-verzoek en retourneert een gecodeerde HTTP-omleidingsreactie volgens de configuratieparameters, zonder verbinding te maken met de applicatieserver of applicatiecode uit te voeren.

Deze aanpak is sneller omdat de server de omleiding kan afhandelen zonder interactie met de applicatie. Tegelijkertijd is de serverconfiguratie minder flexibel dan wat kan worden gedaan met een volwaardige programmeertaal.
htaccess HTTP-omleiding op HTTPS op serverniveau wordt gebruikt voor bulkomleiding. Bijvoorbeeld een redirect van WWW naar een niet-WWW-versie van een domein met HTTPS (of andersom).

Het volgende codefragment is een voorbeeld Nginx-configuraties, dat een omleiding specificeert van http://example.com, http://www.example.com en https://www.example.com naar https://example.com:

server ( luister 80; servernaam voorbeeld.com www.example.com; return 301 https://example.com$request_uri; ) server ( luister 443 ssl; servernaam voorbeeld.com www.example.com; # ssl configuratie ssl aan; ssl_certificaat /pad/naar/certificaat.crt; ssl_certificaat_sleutel /pad/naar/private.key; if ($http_host = www.example.com) ( retourneert 301 https://example.com$request_uri; ) )

Het implementeren van een omleiding op serverniveau verdient de voorkeur, maar is niet altijd haalbaar omdat u mogelijk geen toegang heeft tot de serverconfiguratie. Dit geldt voor gedeelde hosting of platforms zoals Heroku, Azure of Google Platform.

Een HTTPS-omleiding uitvoeren op applicatieniveau

Als u geen toegang heeft tot de serverconfiguratie, of als de omleidingslogica complexer is, moet u de HTTP naar HTTPS-omleiding op applicatieniveau afhandelen.

Deze aanpak is iets langzamer omdat de server het verzoek moet accepteren en de applicatiecode moet verwerken ( of interactie met de applicatieserver) en retourneer het antwoord.

Hoe omleiding op applicatieniveau wordt uitgevoerd, is afhankelijk van de gebruikte programmeertaal en stack. Hier zijn enkele voorbeelden.

Goland-pakket en net/http

U kunt http.Redirect gebruiken.

Robijn op rails

U kunt een omleiding configureren op routerniveau, gebruik een tussenproduct software Rack- of redirect_to-methode in de controller:

beperkingen(host: /www.example.com/) krijgen "*", naar: redirect("https://example.com") end

PHP

Gebruik de headerfunctie om de HTTP-redirect-header te verzenden:

In sommige gevallen is dit de enige mogelijke aanpak. Als u bijvoorbeeld clients moet omleiden van WWW naar een niet-WWW-versie van het domein, van HTTPS naar Heroku of Azure (of vice versa), dan moet u beide domeinen in één applicatie opgeven, een certificaat installeren en het proces doorlopen de omleiding op applicatieniveau via voorwaarden.

Alternatieve manieren om een ​​HTTPS-omleiding uit te voeren

Er zijn meerdere alternatieve manieren omleiden van HTTP naar HTTPS.

In sommige situaties is er geen toegang tot de serverconfiguratie en staat het platform waarop de site wordt gehost het gebruik van een programmeertaal niet toe. Als typisch voorbeeld U kunt Amazon S3 gebruiken voor het hosten van statische sites. In dit geval moet u nagaan of het platform HTTPS-omleidingsparameters biedt die u kunt configureren.

Een andere optie is het gebruik van een zelfstandige, onafhankelijke omleidingsapplicatie. Als u bijvoorbeeld clients moet omleiden van https://alpha.com naar https://beta.com. Vervolgens kunt u voor het alpha.com-domein een andere service of server opgeven die beta.com host als DNS. U kunt ook een omleiding op serverniveau instellen of een applicatie installeren die als omleiding fungeert. In dit geval heeft u ook een geldig certificaat voor alpha.com nodig, dat wordt geïnstalleerd op de plaats waar de omleiding moet worden uitgevoerd.

De adresbalk in browsers trekt meestal geen aandacht, tenzij u een link moet volgen die ergens naar het klembord is gekopieerd. Soms kijken we daar of de overgang correct is, vooral in gevallen met een snelle en oneerlijke omleiding. Maar als we wel kijken, merken we soms een ongebruikelijke toestand op: er hangt een soort hangslot, de kleur van het lettertype is anders en om de een of andere reden zien we https:// in plaats van de gebruikelijke http://. Het is onmogelijk om meteen te begrijpen of het ergens is meegesleept, of dat er iets in de wereld is veranderd, of dat de herinnering faalt. Laten we proberen het uit te zoeken.

Definitie

HTTP — applicatieprotocol gegevensoverdracht die wordt gebruikt om informatie van websites te verkrijgen.

HTTPS- HTTP-protocolextensie die codering ondersteunt door SSL-protocollen en TLS.

Vergelijking

Het verschil tussen HTTP en HTTPS is al merkbaar uit de definities. HTTPS is geen onafhankelijk protocol voor gegevensoverdracht, maar HTTP met een coderingsadd-on. Dit is het belangrijkste en enige verschil. Als het volgens het protocol is HTTP-gegevens onbeschermd worden verzonden, dan zorgt HTTPS ervoor cryptografische bescherming. Dit wordt gebruikt waar autorisatie verantwoordelijk is: op sites van betalingssystemen, postdiensten, in sociale netwerken.

Als de gegevens niet via SSL zijn beveiligd, kan een aanvaller een interceptorprogramma gebruiken dat op het verkeerde moment wordt gelanceerd. Technisch gezien is de implementatie van HTTPS wat ingewikkelder: hiervoor moet de beschermde site een servercertificaat in gebruik hebben, dat de gebruiker wel of niet accepteert. Dit certificaat wordt geïnstalleerd op de server die verbindingen verwerkt. Zowel de gegevens die de opdrachtgever ontvangt als de gegevens die van hem worden ontvangen, zijn gecodeerd. Versleutelingssleutels worden gebruikt om te verifiëren dat de juiste client deze ontvangt en verstrekt.

Een andere technisch verschil— in poorten die worden gebruikt voor toegang via HTTP- en HTTPS-protocollen. De eerste communiceert meestal met poort 80, de tweede met poort 443. De beheerder kan andere poorten openen voor dezelfde doeleinden, maar deze zullen nooit overeenkomen.

Conclusie website

1. HTTP is het gegevensoverdrachtprotocol zelf, HTTPS is een uitbreiding van dit protocol.
2. HTTPS wordt gebruikt voor gecodeerde communicatie.
3. HTTPS wordt ook gebruikt voor autorisatie op servers die dit vereisen verhoogde aandacht naar gegevensbeveiliging.
4. HTTP werkt op poort 80, HTTPS op poort 443.