If I try to search Ebay (using the little box at the upper right corner) through Apache 2.2.0's proxy, I get a "Bad Request" error and the following line shows up in the error log: [Mon Dec 19 08:53:16 2005] [error] [client 127.0.0.1] Digest: uri mismatch - <//search/search.dll?from=R40&satitle=canon+ef+70-200> does not match request-uri <http://search.ebay.com//search/search.dll?from=R40&satitle=canon+ef+70-200>, referer: http://www.ebay.com/ [Mon Dec 19 09:16:36 2005] [error] [client 127.0.0.1] Digest: uri mismatch - <//search/search.dll?from=R40&satitle=canon+ef+70-200> does not match request-uri <http://search.ebay.com//search/search.dll?from=R40&satitle=canon+ef+70-200>, referer: http://www.ebay.com/ [Mon Dec 19 09:17:01 2005] [error] [client 127.0.0.1] Digest: uri mismatch - <//search/search.dll?from=R40&satitle=canon+ef+70-200> does not match request-uri <http://search.ebay.com//search/search.dll?from=R40&satitle=canon+ef+70-200>, referer: http://www.ebay.com/
First question, are you using digest authentication? Second, which browser?
Consider adding: BrowserMatch "MSIE" AuthDigestEnableQueryStringHack=On To your configuration.
Yes, I am using digest authentication. I am using Firefox, and I already have the query hack enabled.
Here are the headers for the transaction: ---------- GET //search/search.dll?from=R40&satitle=canon+ef+70-200 HTTP/1.1 Host: search.ebay.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20051219 Firefox/1.6a1 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Proxy-Connection: keep-alive Referer: http://www.ebay.com/ Cookie: [REMOVED] Proxy-Authorization: Digest [REMOVED] HTTP/1.x 400 Bad Request Date: Mon, 19 Dec 2005 18:06:58 GMT Server: Apache/2.2.0 (Win32) DAV/2 mod_ssl/2.2.0 OpenSSL/0.9.8a Vary: accept-language,accept-charset,User-Agent Accept-Ranges: bytes Connection: close Content-Type: text/html; charset=iso-8859-1 Content-Language: en
Please post: 1) the precise configuration being used 2) a request trace without the relevant parts of the Proxy-Authorization header elided; remove the response="..." field only if you must mod_auth_digest says that the request-URI received was: <http://search.ebay.com//search/search.dll?from=R40&satitle=canon+ef+70-200>, yet in your request trace, the request-URI was not an absoluteURI: GET //search/search.dll?from=R40&satitle=canon+ef+70-200 HTTP/1.1 something is amiss here. What is the browser really sending?
I'm not sure I know what you mean by "precise configuration." I have Apache 2.2.0 with proxy requests on and protected by digest authentication. That's it. The relative URI is what the browser is sending. Those headers are a direct ethereal capture of the traffic. This is the entire conversation between the browser and the proxy. Nothing has been removed except for the cookie, user name, and realm. There is no missing content bodies or anything. ==================== GET //search/search.dll?from=R40&satitle=canon+ef+70-200 HTTP/1.1 Host: search.ebay.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051219 Firefox/1.6a1 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Proxy-Connection: keep-alive Referer: http://www.ebay.com/ Cookie: [REMOVED] Proxy-Authorization: Digest username="[USER]", realm="[REALM]", nonce="YOSSQlsIBAA=6a67edfc40e16f04043939b5ab5c4cabfb709e45", uri="//search/search.dll?from=R40&satitle=canon+ef+70-200", algorithm=MD5, response="5d51354aaf356f005561a4ec59cbeacb", qop=auth, nc=0000003b, cnonce="e254120bbd066c67" HTTP/1.x 400 Bad Request Date: Tue, 20 Dec 2005 14:13:57 GMT Server: Apache/2.2.0 (Win32) DAV/2 mod_ssl/2.2.0 OpenSSL/0.9.8a Vary: accept-language,accept-charset,User-Agent Accept-Ranges: bytes Connection: close Content-Type: text/html; charset=iso-8859-1 Content-Language: en ====================
OK. I can reproduce this, it's something to do with the leading double slash in the path. If you remove the double slash it works OK.
If the client is not sending an absoluteURI in the request-URI when using a proxy it is very broken, that is an RFC2616 MUST condition. This is probably a Firefox 1.6a regression, it gets that much right in 1.5 at least for me; you should file a bug against Firefox for that. It should then also be sending the same absoluteURI in the digest-uri field of the Proxy-Auth header, and if it did so this should work. This probably requires a separate bug against Firefox. As it is, the URI parser will correctly treat: //search/search.dll as a scheme-relative URI when comparing against the request-URI, hostinfo = "search", path = "/search.dll", etc; and then compare that against the absoluteURI for the request. There's not much that can be done about this on the server side, it needs to be fixed client side.
(In reply to comment #6) > ==================== > GET //search/search.dll?from=R40&satitle=canon+ef+70-200 HTTP/1.1 That is NOT a proxy request. So there's something you haven't told us. But bugzilla is not an appropriate forum in which to discuss it further.
> That is NOT a proxy request. So there's something you haven't told us. You are incorrect. There is not something I haven't told you. That is the request that the browser sent to the proxy. There's no conspiracy here.
It looks to me as though the attempt to match the request uri value with the Proxy-Authorization uri parameter value is flawed. The log message says: [Mon Dec 19 08:53:16 2005] [error] [client 127.0.0.1] Digest: uri mismatch - <//search/search.dll?from=R40&satitle=canon+ef+70-200> does not match request-uri <http://search.ebay.com//search/search.dll?from=R40&satitle=canon+ef+70-200>, referer: http://www.ebay.com/ the request-uri value above has been resolved by prepending the leading part '//search' with the fqdn (matching the Host header value) '//search.ebay.com', producing different string. Firefox is clearly not constructing the request correctly because it used just 'search' in the host part of the URL in the request line, but I don't see why a proxy would need to covert that value before comparing it for digest purposes.
[added Scott to CC] The request-uri logged in that error should be the raw, unparsed, unmanipulated Request-URI as received in the request at the proxy.