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