Przedmowa
Po pierwsze: zwykły port 80 -> przepisanie portu 443 NIE naprawi tego. W prawie każdym poprzednim pytaniu, wątku pocztowym, wątku forum itp. Znalazłem, że była to pierwsza ignorancka odpowiedź i kilka razy papugowałem.
Po drugie: Tak, wiem, że nie możesz obsługiwać ruchu HTTP i HTTPS na tym samym porcie. To nie tak.
Scenariusz:
Serwer Apache hostujący wiele witryn poprzez mnożenie portów. Port 80 obsługuje witrynę publiczną. Port 443 obsługuje bezpieczną wersję tej witryny.
Porty 7443, 8443 i 9443 obsługują osobne witryny zabezpieczone protokołem SSL.
Jeśli użytkownik pomyli adres URL lub poda nieprawidłowy link, powiedz http: //nazwa_hosta.tld: 7443 , otrzyma następującą śmieszną stronę:
Zamiast serwera po prostu przekierowuję je na https: //hostname.tld: 7443 .
Moje pytanie brzmi: w jaki sposób, w imię dziury Zeusa, możesz zmodyfikować zachowanie Apache lub ten komunikat o błędzie, aby automatycznie przekierować użytkownika?
Apache oczywiście obsługuje żądanie inne niż https (aby wyświetlić ten komunikat o błędzie), nawet jeśli jest skonfigurowany do HTTPS. Wydaje mi się niezwykle głupie, że nie tylko domyślnie przekierowuję, ale rozumiem, dlaczego zachowali się tak, jak oni, nawet jeśli się z tym nie zgadzam. Moje pytanie brzmi: czy możesz to zmienić? Obsługują błąd GDZIEKOLWIEK, a ponieważ Apache jest konfiguracją róg obfitości, jest oczywiste, że istnieje jakaś dyrektywa, która poradziłaby sobie z tym zachowaniem, ale do tej pory nie udało mi się go znaleźć przez kilka godzin majstrowania.
Aktualizacja:
Próbowałem różnych rzeczy, w tym:
używając
ErrorDocument 400
dyrektyw, aby dostać się do CGI i skryptu PHP, który właśnie wysyłaStatus 301
iLocation
nagłówki. Powoduje to, że strona jest pusta. UżycieErrorDocument 400 https://hostname.tld:7443
po prostu powoduje wyświetlenie tego linku na stronie.Używając prawie każdej kombinacji
mod_rewrite
I lub Google, można wymyślić, w tym ogólne oświadczenia, które całkowicie kierują witryną; te nigdy nie działają. Dosłownie nic nie robią. Zastanawiam się, że Apache wykrywa powyższy błąd, zanim nawet spróbuje przetworzyć dyrektywy przepisujące.
Nie mogę używać przekierowań opartych na portach z powodu niestandardowego użycia portu. Nie mogę używać przekierowań opartych na skryptach, ponieważ nigdy nie są obsługiwane z powodu niezgodności http / https. Prawie jestem skłonny przypisać to błędowi lub niezamierzonemu zachowaniu, ale ktoś miał dość czasu, aby umieścić tam niestandardowy komunikat o błędzie, nie zawracał sobie głowy myśleniem, że może chcesz po prostu pojechać do Adres URL, który już podają ?
źródło
Odpowiedzi:
Myślę, że to prawdopodobnie błąd w tym, jak Apache 2.2 i niższe radzą sobie z tą konkretną okolicznością.
Wygląda na to, że w przypadku
400 Bad Request
błędu odczytu SSL Apache 2.2 nie zwraca kodu odpowiedzi HTTP ani nagłówków, tylko treść odpowiedzi HTTP. Testuję przez telnetting do portu 443 i wysyłanie:Serwer natychmiast zwraca (dla mnie):
Zwróć uwagę na brak kodu odpowiedzi HTTP lub nagłówków HTTP.
Kiedy robię to na serwerze Apache 2.4, otrzymuję:
Jeśli skonfiguruję wiersz ErrorDocument tak jak ty:
Potem dostaję HTML dla przekierowania 302, ale znowu, żaden z nagłówków. Bez kodu odpowiedzi 302 i
Location:
nagłówka przeglądarka nie przekieruje.Spróbuj zaktualizować do Apache 2.4 i sprawdź, czy to działa. Testowałem i potwierdziłem co najmniej Apache 2.4.3, ale nie starałem się znaleźć dokładnie, kiedy to zachowanie zostało zaktualizowane. Podejrzewam, że przy dużej ilości pracy, jaką wykonali przygotowując 2.4, poprawili niepożądane zachowanie jako efekt uboczny.
Istotne błędy httpd Apache:
AKTUALIZACJA
Możesz zmusić błędnego Apache'a, aby dał ci pożądane zachowanie (przekierowanie), każąc skryptowi wydrukować nagłówki (które nie zostaną wysłane do klienta), a następnie ręcznie wydrukować ponownie żądane nagłówki. Oto podstawowy skrypt Perla działający pod Apache 2.2.22:
Należy pamiętać, że istnieją inne powody, dla których 400 może zostać wygenerowane, poza rozmową z portem SSL bez SSL. Najłatwiejszym sposobem ustalenia tego jest poszukiwanie
HTTPS
zmiennej środowiskowej. Jeśli jest ustawiony, protokół SSL został poprawnie wynegocjowany i coś innego powoduje 400 (nie rób sztuczki z podwójnym nagłówkiem, jeśli tak jest). JeśliHTTPS
nie jest ustawiony, zwróć przekierowanie jak wyżej.źródło
<javascript
tag i mieć szczęście z przekierowaniem hakowania w ten sposób, ale jak dotąd nie kostka do gry. Wydaje się, że nic w tym zakresie nie jest obsługiwane w sposób, który byłby zgodny z dość sztywnąMożesz to naprawić za pomocą mod-rewrite. Ustaw regułę, aby dopasować wszystko. Zobacz tę odpowiedź na Stackoverflow
źródło
sites-available
katalog. Nawet jeśli przekierujesz go do bzdur lub przekierujesz na inną stronę, inny port itp., Po prostu ładuje 400 błędnych żądań.