Как только запрос отправлен на http://www.mydomain.com/cart/, если в запросе есть какие-либо конфиденциальные данные, будет слишком поздно.Заставь его сломаться!По крайней мере, это даст вам понять, что с вашими ссылками что-то не так.Более подробная информация в предыдущих ответах:
[...] к моменту поступления запросасервер, уже слишком поздноЕсли есть MITM, он выполнил свою атаку (или ее часть) до того, как вы получили запрос.
Лучшее, что вы можете сделать к тому времени, это ответить без какого-либо полезного контента.В этом случае может быть целесообразно перенаправление (с использованием 301 или 302 и заголовка Location).Однако это может скрыть проблемы, если пользователь (или даже вы как разработчик) игнорирует предупреждения (в этом случае браузер будет следовать перенаправлению и почти прозрачно повторять запрос).
Поэтому я простопредлагаем вернуть статус 404:
http://yoursite/ и https://yoursite/ фактически являются двумя различными сайтами.Нет никаких оснований ожидать, что 1: 1 отобразит все ресурсы из пространств URI от одного к другому (точно так же, как вы могли бы иметь совершенно другую иерархию для ftp://yoursite/). - Подробнееважно отметить, что это проблема, которая должна рассматриваться в восходящем направлении: ссылка, которая привела вашего пользователя к этому ресурсу с использованием
http://, должна рассматриваться как неработающая.Не заставляйте это работать автоматически.Хорошо иметь статус 404 для ресурса, которого там не должно быть.Кроме того, возвращать сообщение об ошибке при наличии ошибки - это хорошо: это заставит вас (или, по крайней мере, напомнит) разработчику, что вам нужно исправить страницу / форму / ссылку, которая привела к этой проблеме.
РЕДАКТИРОВАТЬ: (Пример)
Допустим, у вас есть http://example.com/, небезопасный раздел вашего сайта, который позволяет пользователю просматриватьПредметы.Они не вошли в систему на этом этапе, так что это нормально делать по обычному HTTP.
Теперь пришло время корзины / оплаты.Вы хотите HTTPS.Вы отправляете пользователя на https://example.com/cart/.Если одна из ссылок, которая отправляет пользователя в корзину, использует простой HTTP (т. Е. http://example.com/cart/), это ошибка разработки.Это просто не должно быть там.Прерывание процесса, когда вы думали, что отправляете на https://example.com/cart/, позволяет разработчику увидеть его (и после исправления у пользователя никогда не должно быть проблем).
Если это просто точкадля раздела HTTPS вашего сайта (обычно это HTTP-запрос GET через ссылку где-то), это не обязательно такой большой риск.
Когда автоматические перенаправления становятся еще более опасными, это когда они скрывают большие проблемы.
Например, вы находитесь на https://example.com/cart/creditcarddetails и заполнили некоторую информацию, которая на самом деле должна оставаться поверх SSL.Однако разработчик допустил ошибку, и в форме используется простая ссылка http://.Кроме того, разработчик (в конце концов, пользователь / человек) нажал «Не показывать мне это сообщение снова» в Firefox, когда он говорит: «Предупреждение: вы переходите с защищенной страницы на незащищенную страницу» (кстати, к сожалению, Firefox предупреждает апостериорно: он уже сделал небезопасный запрос к тому времени, когда показывает пользователю это сообщение).Теперь этот запрос GET / POST с конфиденциальными данными сначала отправляется на эту неправильную обычную ссылку http://, и автоматическое перезапись указывает браузеру повторить запрос еще раз https://.Это выглядит хорошо, потому что, с точки зрения пользователя, все это произошло за доли секунды.Однако это не так: конфиденциальные данные были отправлены в незашифрованном виде.
То, что простой HTTP-раздел о том, что должно быть только по HTTPS, не делает ничего полезного, на самом деле помогает вам понять, что не так, более четко.Так как пользователи никогда не должны оказаться там, если ссылки реализованы правильно, для них это не проблема.