Safari - "400 Bad Request" bei einer bestimmten Webseite

[Yurei]

Hi Zusammen,

habe mich hier angemeldet, weil ich gerade ein bisschen mit meinem Latein am Ende bin.
Ich habe hier ein Problem bei einer einzigen mit Basic Auth gesicherte Webseite (nur aus dem Firmen-VPN erreichbar).
Jedes Mal wenn ich die Seite aufrufe, bekomme ich den HTTP-400-Statuscode:

Die Nginx-Logs sind nicht besonders aufschlussreich. Abseits der 301-Redirect-Einträge nur diese Zeile:

2a09:xxx:xxx:xxx::xxx:xx - - [03/Nov/2024:13:11:30 +0100] "GET /favicon.ico HTTP/2.0" 401 172 "https://foo.bar.de/baz/web/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/18.1 Safari/605.1.15"

Die Webanwendung die hinter dem Nginx läuft ist eine Abscheulichkeit und loggt leider überhaupt nicht.

• Die Website funktioniert gut mit Firefox.
• In einem privaten Fenster, oder mit einem anderen Profil in Safari geht es auch problemlos.
• iPhone oder iPad mit dem selben Profil haben keine Probleme

Das habe ich schon ausprobiert:

• Safari -> Einstellungen -> Datenschutz -> 'Websitedaten verwalten...' -> Alles löschen
• Develop -> Caches für alle Profile leeren
• History komplett gelöscht
• Basic Auth ausgeschaltet

Jemand noch eine Idee was ich testen könnte? Dankeschön


Edit: Jetzt habe ich doch glatt die Systeminfos vergessen:
MacBook Pro M3 Pro
MacOS 15.1
Safari 18.1

 

[MrChad]

• Die Website funktioniert gut mit Firefox.
• In einem privaten Fenster, oder mit einem anderen Profil in Safari geht es auch problemlos.

Du hast entweder noch
Session Cookies, die die Logik deines Webservers durcheinanderbringen oder
irgendwelche Seiten.Fragmente in deinem Cache, die Safari fälschlicherweise verwendet.

Sowas kommt vor.
Beides wegmachen, dann geht's wieder.

 

[Yurei]

Beides wegmachen, dann geht's wieder.

Hi, danke für deine Antwort.
Wie mache ich das? Laut Apple habe ich das ja schon Cookies gelöscht:
https://support.apple.com/guide/safari/manage-cookies-sfri11471/mac
Und Cache auch mit dem Develop-Menü.

 

[Difool]

Lade die Website in Safari mal bei offenen Developertool per ⌘ + ⌥ + R oder ⇧+Reload-Button.

Reicht das nicht, dann direkt im Developertool unter dem „Netzwerk“-Tab:

Häkchen setzen bei „Caches deaktivieren“ und Reload.

 

[Yurei]

Lade die Website in Safari mal bei offenen Developertool per ⌘ + ⌥ + R oder ⇧+Reload-Button.

Reicht das nicht, dann direkt im Developertool unter dem „Netzwerk“-Tab:

Anhang anzeigen 443593

Häkchen setzen bei „Caches deaktivieren“ und Reload.

Danke für deine Antwort. Habe gerade beides probiert, leider ohne Erfolg.

 

[Difool]

Mmh …
Alternativ vergleiche mal die Website Header in Firefox und Safari.

Dev-Tool Safari > Netzwerk > obersten Punkt auswählen und Header anzeigen lassen:

Beim letzten Tab „Sicherheit“ kannst du das Zertifikat kontrollieren usw.

PS:
Auch mal mit „private tab“ in Safari versuchen.

 

[Yurei]

Sehr guter Hinweis! Danke!
Habe dank deinem Tipp herausgefunden, dass Safari den Auth-Part mehrfach schickt:



Hier aus dem privaten Fenster:


Da habe ich etwas recherchiert und das Loglevel von Nginx verstellt und siehe da:

2024/11/03 15:05:24 [info] 20326#100213: *3479 client sent duplicate header line: "authorization: Basic dGVpcxxxxxxxxxxxxxxxxxxxxxxxxx", previous value: "authorization: Basic dGVpcxxxxxxxxxxxxxxxxxxxxxxxxx" while reading client request headers, client: 2a09:xxx:xxxx:xxx::xx:xx, server: foo.bar.de, host: "foo.bar.de"

Jetzt stelle ich mir natürlich die Frage, warum tut Safari das (auch wenn ich Auth serverseitig temporär deaktiviert habe) und wie verhindere ich es?
Bisher konnte ich da noch keine Lösung finden.

 

[Difool]

Wenn du Pech haben solltest, dann ist es ein Bug in Safari, welchen du melden solltest/könntest:
https://bugs.webkit.org/enter_bug.cgi?product=WebKit
Zumal diese Art Bugs sich bei Safari bereits quasi „wie eine Tradition“ hartnäckig halten oder gehalten werden?
Falls es nicht ein „across origins“-Problem sein sollte.

Siehe:
https://stackoverflow.com/questions...-the-authorization-header-when-following-a-sa

 

[Elys]

Oder Safari unterstützt dieses Standard nicht oder nur rudimentär, was zu Fehlfunktionen führen kann. Wenn mit Safari was nicht hinhaut, sollte man nicht vergessen, daß dieser Browser nicht alle gängigen Standards unterstützt.

 

[Yurei]

Wenn du Pech haben solltest, dann ist es ein Bug in Safari, welchen du melden solltest/könntest:
https://bugs.webkit.org/enter_bug.cgi?product=WebKit
Zumal diese Art Bugs sich bei Safari bereits quasi „wie eine Tradition“ hartnäckig halten oder gehalten werden?
Falls es nicht ein „across origins“-Problem sein sollte.

Siehe:
https://stackoverflow.com/questions...-the-authorization-header-when-following-a-sa

Glaube auch mittlerweile an einen Bug. Bugreport ist also raus.

Oder Safari unterstützt dieses Standard nicht oder nur rudimentär, was zu Fehlfunktionen führen kann. Wenn mit Safari was nicht hinhaut, sollte man nicht vergessen, daß dieser Browser nicht alle gängigen Standards unterstützt.

Aber auf iOS, iPadOS, im Privaten Fenster oder unter anderem Profil wird der Standard dann unterstützt? Außerdem ist das HTTP Basic auth…

 

[Elys]

Aber auf iOS, iPadOS, im Privaten Fenster oder unter anderem Profil wird der Standard dann unterstützt? Außerdem ist das HTTP Basic auth…

War nur mal eine Vermutung, keine Behauptung. Entweder wird der Standard unterstützt oder nicht.

 

[Yurei]

Ich konnte das Problem für mich etwas erträglicher machen.
Komischerweise speichert Safari "HTTP Basic Auth"-Zugangsdaten nicht in der neuen "Passwords"-App, sondern in der "Keychain Access"-App.
Dort habe ich jetzt die Zugangsdaten gelöscht und schon komme ich wieder auf den Server, es sei denn, ich wähle die Option "Passwort merken".

 

[aheissenberger]

Es ist ein Bug in Safari 18.1 unter MacOS 15.1 und es gibt dazu bereits einen Bugreport:
https://bugs.webkit.org/show_bug.cgi?id=282508

Aktuell funktioniert bei mir auch nur das Löschen der Einträge im "Schlüsselbund" und danach einem Restart von Safari (es müssen auch alle auf Safari basierenden PWAs beendet werden). Zugriff auf die Seiten immer ohne Speicherung der Zugangsdaten

 

[Yurei]

Es ist ein Bug in Safari 18.1 unter MacOS 15.1 und es gibt dazu bereits einen Bugreport:
https://bugs.webkit.org/show_bug.cgi?id=282508

Aktuell funktioniert bei mir auch nur das Löschen der Einträge im "Schlüsselbund" und danach einem Restart von Safari (es müssen auch alle auf Safari basierenden PWAs beendet werden). Zugriff auf die Seiten immer ohne Speicherung der Zugangsdaten

Ich weiß. Der Report ist von mir.