www-apache-bugdb mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Gripshover <...@niroinc.com>
Subject Re: FW: mod_proxy/9772: proxy: Ignoring duplicate HTTP header...
Date Fri, 15 Feb 2002 17:43:22 GMT
Graham, Joshua,

Forgive me if you recvd my comments yesterday already.
I'm not sure if the reply recip was correct, so i added a few.

Re: Comments?
I would say no, proxy should not add a content-type header
to responses without one.

Let the browser figure it out.  That's the way it would have to
work if it were connecting directly (not through any proxy).

Also, the older apache proxy (doesn't have this problem) isn't
adding a content-type header of it's own.

New today, at the bottom of this mail I am forwarding another report
of problems being caused by 1.3.23 proxy improperly adding a
content-type header from Markus Schuh.

Cheers,
Jonathan

> From minfrin@sharp.fm Thu Feb 14 02:45:33 2002
> Date: Thu, 14 Feb 2002 09:45:10 +0200
> From: Graham Leggett <minfrin@sharp.fm>
> X-Accept-Language: en
> MIME-Version: 1.0
> To: dev@httpd.apache.org
> CC: jcg@niroinc.com
> Subject: Re: FW: mod_proxy/9772: proxy: Ignoring duplicate HTTP header...
> 
> This is a cryptographically signed message in MIME format.
> 
> --------------msBB0924C6D919B27E65372E6A
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
> 
> Joshua Slive wrote:
> 
> > I really don't know what is going on with the proxy, so it is silly for me
> > to be acting as an intermediary.  I'll just reopen this bug report, and
> > anyone who wants can take a look at it.
> 
> This is a different bug entirely - it's to do with what proxy does when
> it encounters IIS v4.0 brokenness, and website designer brokenness.
> 
> > Subject: Re: mod_proxy/9772: proxy: Ignoring duplicate HTTP header...
> > 
> > No, this patch did not fix the problem.
> > Point a browser to the following url thru apache proxy to see the mess.
> > 
> >   http://cgi3.ebay.com/aw-cgi/eBayISAPI.dll?SignIn
> 
> This patch will definitely not fix this problem, as the problem lies
> partially with ebay. The above URL returns the following response
> headers:
> 
> HTTP/1.1 200 OK
> Server: Microsoft-IIS/4.0
> Date: Thu, 14 Feb 2002 07:17:54 GMT
> Set-Cookie:
> s=AQAAAAEAAAASAAAARgAAAKJkazwin3Q8QDE5Ni4zMC4xMjguMjZlMXRlc3RDb29raWUgJDIkTW96aWxsYS8kTlk0dFlbG1JY3U0NHdxcjBuLzRpLwA*f;
> path=/; domain=.ebay.com
> Set-Cookie: secure_ticket=n; path=/; domain=.ebay.com; secure
> HTTP/1.1 200 OK
> Server: Microsoft-IIS/4.0
> Date: Thu, 14 Feb 2002 07:17:54 GMT
> Set-Cookie:
> s=AQAAAAEAAAASAAAARgAAAKJkazwin3Q8QDE5Ni4zMC4xMjguMjZlMXRlc3RDb29raWUgJDIkTW96aWxsYS8kTlk0dFlbG1JY3U0NHdxcjBuLzRpLwA*f;
> path=/; domain=.ebay.com
> HTTP/1.1 200 OK
> Server: Microsoft-IIS/4.0
> Date: Thu, 14 Feb 2002 07:17:54 GMT
> 
> Your "ignoring duplicate HTTP header" message is triggered by the
> presence of multiple "HTTP/1.1 200 OK" lines, and is the correct
> behavior. There are two additional lines, therefore you get two error
> messages. The solution here is for Ebay to keep their webservers up to
> date.
> 
> What is causing the page to be rendered in plain text however is the
> fact that there is no Content-Type header associated with this page.
> According to RFC2616, a content-type "SHOULD" be present. If it is not
> present, then the client can either guess what it is based on file
> extension or looking at a few bytes, otherwise it should be
> "application/octet-stream".
> 
> So - the question is, should proxy be adding a content-type header to
> responses without one? If we don't, we effectively tell the browser "you
> deal with the broken content".
> 
> Comments?
> 
> Regards,
> Graham
> -- 
> -----------------------------------------
> minfrin@sharp.fm		"There's a moon
> 					over Bourbon Street
> 						tonight..."
------------- Begin Forwarded Message -------------

From: "Schuh, Markus" <markus.schuh@sdm.de>
To: "'jcg@niroinc.com'" <jcg@niroinc.com>
Subject: Re. proxy/9772: Ignoring duplicate HTTP header...
Date: Fri, 15 Feb 2002 17:59:37 +0100
MIME-Version: 1.0

Hi Jonathan,

Looking for an existing Apache proxy PR i found your's:
   http://bugs.apache.org/index.cgi/full/9772

Personal Pages on www.ebay.de viewed with Netscape
via apache 1.3.23 proxy were displayed as text/plain too.
I believe this is the same problem a you described it.

Could you please try to verify my analysis (below) and send
it to the apache developers, if i'm right? Thanx!
(May be i could add my comments directly to the
 PR via "cc: apbugs@Apache.Org", but I'm not sure for that.)

Problem analysis:
The original response does not contain any "Content-Type"
header. Apache proxy adds this header:
  Content-Type: text/plain
Therefore Netscape displays the Response as plain text.

A quick check/hack: Change Apache's "DefaultType" directive
 in httpd.conf to "text/html", restart apache and try the page again.

I don't think apache should add this header to proxy
requests. The request should have a Content-Type but
it does not have to.

http://www.w3.org/Protocols/rfc2616/rfc2616-sec7.html

> Any HTTP/1.1 message containing an entity-body SHOULD include a
> Content-Type header field defining the media type of that body.
> If and only if the media type is not given by a Content-Type field,
> the recipient MAY attempt to guess the media type via inspection
> of its content and/or the name extension(s) of the URI used
> to identify the resource.
> If the media type remains unknown, the recipient SHOULD treat
> it as type "application/octet-stream". 

By the way:
The same page viewed with IE 6 was displayed as it should
(as text/html). IE seems to ignore the Content-Type header
and interpret the source of the page on it's own. That
does not surprise me: I think the same "interpretation freedom"
leads to an IE which is starting executables marked as
"Content-Type: audio/x-wav" (misused by a lot o e-mail worms.)

-- 
Markus Schuh

------------- End Forwarded Message -------------

Mime
View raw message