Нека популяризираме разликата между статусните кодове 301 и 302
Ресурсът 301 Преместен постоянно е преместен на ново място и всякакви бъдещи препратки към този ресурс трябва да използват един от няколкото URI-та, върнати в този отговор. Ако е възможно, клиентите с редактиране на връзки трябва автоматично да променят искания адрес към адрес, върнат от сървъра. Този отговор също е кешируем, освен ако не е посочено друго.
Ресурсите, поискани от 302 Found, сега временно отговарят на заявки от различен URI. Тъй като такива пренасочвания са временни, клиентът трябва да продължи да изпраща бъдещи заявки към оригиналния адрес. Този отговор е кешируем само ако е посочено в Cache-Control или Expires.
Най-често срещаният сценарий за 301 е използването на скокове между домейн имена.
Например, ние посещавамеhttp://www.baidu.comще прескоча къмhttps://www.baidu.comСлед изпращане на заявката ще бъде върнат статус код 301, след което ще се върне дадено местоположение, което ще поиска нов адрес, и браузърът ще вземе този нов адрес за достъп.
Забележка: 301 заявки могат да бъдат кеширани, т.е. като погледнете кода на статуса, можете да откриете, че накрая пише от кеша.
Или променяте името на уеб страницата си от php на html, и в процеса ще се случи и постоянно пренасочване.
302 се използва за временни скокове
Например, потребители, които не са влезли, се пренасочват към страницата за вход, когато посетят потребителския център.
Посещението на страница 404 пренасочва към началната страница.
Конфигурацията на Alibaba Cloud Load Balancing SLB е следната:
Използваме http, за да пренасочваме към https, очевидното намерение е да пренасочваме постоянно, не временно, но тук Alibaba Cloud ми дава това, което връщамеВременно пренасочване на статус код 302。 Както е показано по-долу:
Кодът за статус на връщане, тестван онлайн с Webmaster's Home and Aizhan Network, е 302, а аз също използвах кода, за да върна статусния код 302.
Казус: Пренасочванията на сайта 302 бяха наказани от GOOGLE за неправомерна употреба
Business.com е най-голямата бизнес търсачка и категория в интернет, с репутация за професионално предоставяне на бизнес информация, включително близо 190 000 уеб страници. Ако потърсите в Google ключовата дума "бизнес", сайтът ще бъде класиран на първо място. Въпреки това, на 5 септември 2010 г. Business.com се сблъска с нещо странно: PR на началната страница се промени от 8 на 0 и началната страница не можеше да бъде намерена в резултатите от търсенето на Google. За щастие, само началната страница е тази, която "изчезва". Но за щастие, началната страница се върна в резултатите от търсенето на Google на следващия ден, но PR все още беше 0.
Днес съм на Baidu webmaster платформата "HTTPS автентикация" и открих, че https верификация на сайта не е успяла, което събуди бдителността ми.
Няма разлика между 302 и 301 по отношение на функционалността, но той би трябвало да има много голямо влияние върху SEO, или се разделя на два различни статусни кода.
Тъй като този сайт използва интелигентна DNS резолюция, можете да задавате различни адреси за различни региони, този сайт прави разлика само между местни и чуждестранни, вътрешен Alibaba Cloud, чуждестранен Amazon AWS, както е показано на фигурата по-долу:
Използвайки домашния ping тест на уебмастъра, открих, че има 29 независими IP адреса, въпреки че адресите за резолюция са различни, всички пренасочват URL http към https.
Тествах Alibaba Cloud SLB и Amazon CDN с код и резултатът, върнат чрез HTTP пренасочване https, е следният:
Единствената разлика при заявките е, че при тестване на Amazon трябва да направите заявка чрез прокси, за да можете да отидете в чужбина, за да анализирате и прикачите кода:
Преди тестване е подаден тикет до Alibaba Cloud, както е показано на фигурата по-долу:
Към този момент проблемът не е решен и причината не е обяснена.
(Край)
|
Публикувано в 20.06.2019 г. 10:43:29 ч.
|
|
|
|
Хазяин|
Публикувано в 21.06.2019 г. 10:19:32 ч.
|
