Bug 37959 - digest URI mismatch with proxy
Summary: digest URI mismatch with proxy
Status: RESOLVED INVALID
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_auth_digest (show other bugs)
Version: 2.2.0
Hardware: Other other
: P2 normal (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-12-19 18:28 UTC by Jerry Baker
Modified: 2006-07-13 09:32 UTC (History)
1 user (show)



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jerry Baker 2005-12-19 18:28:33 UTC
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/
Comment 1 Paul Querna 2005-12-19 18:44:39 UTC
First question, are you using digest authentication?

Second, which browser?
Comment 2 Paul Querna 2005-12-19 18:45:19 UTC
Consider adding:
 BrowserMatch "MSIE" AuthDigestEnableQueryStringHack=On
To your configuration.
Comment 3 Jerry Baker 2005-12-19 18:51:20 UTC
Yes, I am using digest authentication. I am using Firefox, and I already have
the query hack enabled.
Comment 4 Jerry Baker 2005-12-19 19:12:44 UTC
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
Comment 5 Joe Orton 2005-12-20 11:45:01 UTC
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?
Comment 6 Jerry Baker 2005-12-20 15:16:34 UTC
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
====================
Comment 7 Joe Orton 2005-12-20 15:57:02 UTC
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.
Comment 8 Joe Orton 2005-12-20 16:09:02 UTC
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.
Comment 9 Nick Kew 2005-12-20 16:38:40 UTC
(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. 
Comment 10 Jerry Baker 2005-12-20 16:42:32 UTC
> 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.
Comment 11 Scott Lawrence 2006-07-13 15:29:02 UTC
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.
Comment 12 Joe Orton 2006-07-13 16:32:42 UTC
[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.