You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Graham Leggett <mi...@sharp.fm> on 2000/01/24 16:26:11 UTC
RFC conceptual problem - please help
Hi all,
I am trying to track down a bug in the reverse proxy code, and I need
some help in understanding what the correct Apache behavior should be.
In short, Apache is returning cached documents to the browser without a
corresponding MIME type in the headers. The browser (in our case, a WAP
phone) then has no idea what to do with the data and throws an error.
Here is the long explanation of the problem:
A request gets sent to the Apache reverse proxy, like so:
browser --> Apache
GET /kpno/ HTTP/1.0
Via: 1.0 WAPGW3
Connection: Keep-Alive
User-Agent: EricssonR320/R1A
Host: mmm.wapplaza.nl
Accept: application/vnd.wap.wmlc, application/vnd.wap.wbxml,
application/vnd.wap.wmlscriptc, */*, text/vnd.wap.wml, text/xml,
text/vnd.wap.wmlscript
Accept-Language: en
The document at this URL is actually a document living on a MS IIS
server running on the backend using ProxyPass. Apache sends a request to
this server like so:
Apache --> MSIIS
GET /kpno/ HTTP/1.0
Host: enlint009.ericsson.nl
Accept: application/vnd.wap.wmlc, application/vnd.wap.wbxml,
application/vnd.wap.wmlscriptc, */*, text/vnd.wap.wml, text/xml,
text/vnd.wap.wmlscript
Accept-Language: en
User-Agent: EricssonR320/R1A
Via: 1.0 WAPGW3
If-Modified-Since: Mon, 24 Jan 2000 07:26:42 GMT
Because Apache has already cached the document, it sends a request to
check if the document is up to date, adding the If-Modified-Since line.
MS IIS, answering the request, says that no, the document has not been
modified since the date, and returns this:
Apache <-- MSIIS
HTTP/1.1 304 Not Modified
Server: Microsoft-IIS/4.0
Date: Mon, 24 Jan 2000 12:39:13 GMT
Content-Location: http://enlint009.ericsson.nl/kpno/index.wml
ETag: "0252a5c3c66bf1:f4c"
Apache receives the above header, and gives the following *incorrect*
response back to the browser:
browser <-- Apache
HTTP/1.0 200 OK
Server: Microsoft-IIS/4.0
Date: Mon, 24 Jan 2000 12:39:13 GMT
Content-Location: http://enlint009.ericsson.nl/kpno/index.wml
ETag: "0252a5c3c66bf1:f4c"
<?xml version="1.0"?>
<!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN"
"http://www.wapforum.org/DTD/wml_1.1.xml">
<wml>
...
[snip rest of body]
Notice how the headers returned to the browser are the exact same
headers that were returned from MSIIS - without the MIME type!
Who is at fault here? MSIIS or Apache?
I am assuming that the fix is to get Apache to send the headers cached
with the data, rather than the incomplete headers returned by MSIIS. I
would like to find out whether this is an Apache bugfix, or an IIS bug
workaround.
Can anyone give me the correct RFC behavior?
Regards,
Graham
--
-----------------------------------------
minfrin@sharp.fm "There's a moon
over Bourbon Street
tonight...
Re: RFC conceptual problem - please help
Posted by Graham Leggett <mi...@sharp.fm>.
Dean Gaudet wrote:
> looks like apache is at fault. see rfc2616 section 10.3.5:
>
> If the conditional GET used a strong cache validator (see section
> 13.3.3), the response SHOULD NOT include other entity-headers.
> Otherwise (i.e., the conditional GET used a weak validator), the
> response MUST NOT include other entity-headers; this prevents
> inconsistencies between cached entity-bodies and updated headers.
>
> so the proxy should always used the cached entity headers for 304
> responses.
Ok.
So, in theory that means that if the check of the expired item in the
cache returns HTTP_NOT_MODIFIED, then we should just return the cached
headers and ignore all the headers that come from the source server?
If so, then I have a really simple patch to fix the problem...
Regards,
Graham
--
-----------------------------------------
minfrin@sharp.fm "There's a moon
over Bourbon Street
tonight...
Re: RFC conceptual problem - please help
Posted by Dean Gaudet <dg...@arctic.org>.
On Mon, 24 Jan 2000, Graham Leggett wrote:
> Notice how the headers returned to the browser are the exact same
> headers that were returned from MSIIS - without the MIME type!
>
> Who is at fault here? MSIIS or Apache?
looks like apache is at fault. see rfc2616 section 10.3.5:
If the conditional GET used a strong cache validator (see section
13.3.3), the response SHOULD NOT include other entity-headers.
Otherwise (i.e., the conditional GET used a weak validator), the
response MUST NOT include other entity-headers; this prevents
inconsistencies between cached entity-bodies and updated headers.
so the proxy should always used the cached entity headers for 304
responses.
Dean