Laten we het verschil tussen statuscodes 301 en 302 populair maken
De 301 Permanent Moved Resource-bron is permanent verplaatst naar een nieuwe locatie, en toekomstige verwijzingen naar deze bron moeten een van de verschillende URI's gebruiken die in dit antwoord worden teruggegeven. Indien mogelijk moeten clients met linkbewerking het gevraagde adres automatisch aanpassen naar het adres dat door de server wordt teruggestuurd. Deze respons is ook cache-baar, tenzij anders gespecificeerd.
Bronnen die door 302 Found zijn aangevraagd, reageren nu tijdelijk op verzoeken van een andere URI. Omdat dergelijke redirects tijdelijk zijn, moet de client toekomstige verzoeken naar het oorspronkelijke adres blijven sturen. Deze reactie is alleen cachebaar als deze is gespecificeerd in Cache-Control of Expires.
Het meest voorkomende scenario voor 301 is het gebruik van domeinnaamsprongen.
Bijvoorbeeld, we bezoekenhttp://www.baidu.comZal springen naarhttps://www.baidu.comNa het versturen van het verzoek wordt een 301-statuscode teruggegeven, waarna een locatie wordt teruggegeven, waarbij een nieuw adres wordt aangegeven en de browser dit nieuwe adres gebruikt om toegang te krijgen.
Opmerking: 301-verzoeken kunnen worden gecachet, dus door naar de statuscode te kijken, zie je dat deze aan het einde van de cache staat.
Of je verandert de naam van je webpagina van php naar html, en daarbij vindt er ook een permanente doorleiding plaats.
302 wordt gebruikt voor tijdelijke sprongen
Gebruikers die niet zijn ingelogd worden bijvoorbeeld doorgestuurd naar de inlogpagina wanneer ze het gebruikerscentrum bezoeken.
Het bezoeken van een 404-pagina leidt door naar de startpagina.
De configuratie van Alibaba Cloud Load Balancing SLB is als volgt:
We gebruiken http om te redirecten naar https, de voor de hand liggende bedoeling is om permanent te redirecten, niet tijdelijk, maar hier geeft Alibaba Cloud mij wat we teruggevenTijdelijke redirect-statuscode 302。 Zoals hieronder getoond:
De retourstatuscode die online is getest met Webmaster's Home en Aizhan Network is 302, en ik heb de code ook gebruikt om de statuscode 302 terug te geven.
Case study: Website 302-doorverwijzingen werden door GOOGLE bestraft wegens onjuist gebruik
Business.com is de grootste zakelijke zoekmachine en categorie op het internet, met een reputatie voor het professioneel leveren van bedrijfsinformatie, waaronder bijna 190.000 webpagina's. Als je op Google zoekt naar het trefwoord "bedrijf", wordt de website als eerste gerangschikt. Echter, op 5 september 2010 kwam Business.com iets vreemds tegen: de homepage PR veranderde van 8 naar 0, en de homepage was niet meer te vinden in de Google-zoekresultaten. Gelukkig is het alleen de homepage die "verdampt". Maar gelukkig kwam de startpagina de volgende dag weer terug in de zoekresultaten van Google, maar de PR was nog steeds 0.
Ik zit vandaag op het Baidu-webmasterplatform "HTTPS authentication" en ontdekte dat een site-httpsverificatie faalde, wat mijn waakzaamheid opwekte.
Er is geen verschil tussen 302 en 301 qua functie, maar het zou wel een grote impact moeten hebben op SEO, of het is verdeeld in twee verschillende statuscodes.
Omdat deze site intelligente DNS-resolutie gebruikt, kun je verschillende adressen instellen voor verschillende regio's; deze site maakt alleen onderscheid tussen binnenlandse en buitenlandse, binnenlandse Alibaba Cloud, buitenlandse Amazon AWS, zoals te zien is in de onderstaande figuur:
Met behulp van de home ping-test van de webmaster ontdekte ik dat er 29 onafhankelijke IP's zijn, hoewel de resolutieadressen verschillen, maar ze leiden allemaal de URL http om naar https.
Ik heb Alibaba Cloud SLB en Amazon CDN getest met code, en het resultaat dat HTTP redirect https teruggeeft is als volgt:
Het enige verschil in verzoeken is dat je bij het testen van Amazon een verzoek via een proxy moet doen, zodat je naar het buitenland kunt gaan om de code te parsen en toe te voegen:
Voor het testen is er een ticket ingediend bij Alibaba Cloud, zoals weergegeven in de onderstaande figuur:
Tot nu toe is het niet opgelost en is de reden niet uitgelegd.
(Einde)
|
Geplaatst op 20-06-2019 10:43:29
|
|
|
|
Huisbaas|
Geplaatst op 21-06-2019 10:19:32
|
