TestBasicAuth fails on Safari/Windows, as the browser prompts for credentials despite the credentials already appearing in the URL.
This is Safari/WebKit's fault, since they fail to pass the appropriate settings to WinInet to work around this issue. I've filed it as WebKit bug 15441; we probably won't be able to fix it on our end until they fix it on theirs. (They'll probably add some new configurable preference to support this.) http://bugs.webkit.org/show_bug.cgi?id=15441
Description
TestBasicAuth fails on Safari/Windows, as the browser prompts for credentials despite the credentials already appearing in the URL.
This is Safari/WebKit's fault, since they fail to pass the appropriate settings to WinInet to work around this issue. I've filed it as WebKit bug 15441; we probably won't be able to fix it on our end until they fix it on theirs. (They'll probably add some new configurable preference to support this.) http://bugs.webkit.org/show_bug.cgi?id=15441
If you look at the HTTP headers over the wire, you'll see that when a proxy is used, Safari doesn't pass an "Authorization" HTTP header, but simply requests "GET http://joeuser:www.rahul.net'>a.b.C.D@www.rahul.net/joeuser/", which is not valid.
This is doubly unfortunate because (as discussed in bug 15441) the source code for the Safari network code isn't open; WebKit is configured to use a Windows port of CFNetwork whose source is not (yet?) available.
In principle, we can workaround this bug on the Java side, but we'd have to modify Jetty code to do it. When you send "GET http://joeuser:www.rahul.net'>a.b.C.D@www.rahul.net/joeuser/" to Jetty, it throws an exception in HttpRequest.decodeRequestLine, which is before any of our handlers get to see the request.
HttpException(400,Bad Request,http://joeuser:www.rahul.net'>a.b.C.D@www.rahul.net/joeuser/)
at org.mortbay.http.HttpRequest.decodeRequestLine(HttpRequest.java:748)
at org.mortbay.http.HttpRequest.readHeader(HttpRequest.java:247)
at org.mortbay.http.HttpConnection.readRequest(HttpConnection.java:862)
at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:908)
at org.mortbay.http.HttpConnection.handle(HttpConnection.java:833)
at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244)
at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357)
at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534)
Dan Fabulich - 16/Oct/07 05:37 PM Bug 15441 is fixed in Safari seed 310A15. But unfortunately there's a more subtle bug 15535 in that seed. http://bugs.webkit.org/show_bug.cgi?id=15535
If you look at the HTTP headers over the wire, you'll see that when a proxy is used, Safari doesn't pass an "Authorization" HTTP header, but simply requests "GET http://joeuser:www.rahul.net'>a.b.C.D@www.rahul.net/joeuser/", which is not valid.
This is doubly unfortunate because (as discussed in bug 15441) the source code for the Safari network code isn't open; WebKit is configured to use a Windows port of CFNetwork whose source is not (yet?) available.
In principle, we can workaround this bug on the Java side, but we'd have to modify Jetty code to do it. When you send "GET http://joeuser:www.rahul.net'>a.b.C.D@www.rahul.net/joeuser/" to Jetty, it throws an exception in HttpRequest.decodeRequestLine, which is before any of our handlers get to see the request.
HttpException(400,Bad Request,http://joeuser:www.rahul.net'>a.b.C.D@www.rahul.net/joeuser/)
at org.mortbay.http.HttpRequest.decodeRequestLine(HttpRequest.java:748)
at org.mortbay.http.HttpRequest.readHeader(HttpRequest.java:247)
at org.mortbay.http.HttpConnection.readRequest(HttpConnection.java:862)
at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:908)
at org.mortbay.http.HttpConnection.handle(HttpConnection.java:833)
at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244)
at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357)
at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534)
Bug
Open
Major
TestBasicAuth fails on Safari/Windows
If you look at the HTTP headers over the wire, you'll see that when a proxy is used, Safari doesn't pass an "Authorization" HTTP header, but simply requests "GET http://joeuser:www.rahul.net'>a.b.C.D@www.rahul.net/joeuser/", which is not valid.
This is doubly unfortunate because (as discussed in bug 15441) the source code for the Safari network code isn't open; WebKit is configured to use a Windows port of CFNetwork whose source is not (yet?) available.
In principle, we can workaround this bug on the Java side, but we'd have to modify Jetty code to do it. When you send "GET http://joeuser:www.rahul.net'>a.b.C.D@www.rahul.net/joeuser/" to Jetty, it throws an exception in HttpRequest.decodeRequestLine, which is before any of our handlers get to see the request.
HttpException(400,Bad Request,http://joeuser:www.rahul.net'>a.b.C.D@www.rahul.net/joeuser/)
at org.mortbay.http.HttpRequest.decodeRequestLine(HttpRequest.java:748)
at org.mortbay.http.HttpRequest.readHeader(HttpRequest.java:247)
at org.mortbay.http.HttpConnection.readRequest(HttpConnection.java:862)
at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:908)
at org.mortbay.http.HttpConnection.handle(HttpConnection.java:833)
at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244)
at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357)
at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534)