W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1999

RE: Proxies and broken HTTP

From: Scott Lawrence <lawrence@agranat.com>
Date: Fri, 10 Sep 1999 08:46:07 -0400
To: <http-wg@hplb.hpl.hp.com>
Message-ID: <003d01befb8a$7367e580$954768c0@oyster.agranat.com>

> The particular case I have in mind is an origin server
> (which shall remain nameless) returning an entity body
> with a 304. The client-side of our proxy is liberal
> enough to cope with this on receipt, but the server-
> side conservatively refuses to forward it.
>
> In this scenario it seems pretty reasonable to discard
> the entity:

Sounds right to me.

> [...] But trying to generalize to other
> kinds of upstream and downstream bad behaviour opens up
> a can of worms. The options seem to be,
>
> 1. Forward broken HTTP.
>
> 2. Enforce strict conformance by responding to all bad
>    requests with 400s and all bad replies with 502s.
>
> 3. Fixup up bad requests/replies on their way through
>    wherever possible.
>
> (1) is pretty much out of the question; (2) is over the
> top; and (3) is completely unspecified, so liable to be
> done differently be different proxy implementors.

I think that the only sensible thing to do is to figure each case out as
they arise; you've arrived at a good solution for this one, and it
sounds like you have it right - the server side is stricter than the
client side.

I would make sure that your log files include the Server: header for any
offending responses, so that proxy operators can complain effectivly to
vendors.  I assume that you've not kept silent to the (nameless) vendor
for this obvious bug.

--
Scott Lawrence           Director of R & D        <lawrence@agranat.com>
Agranat Systems, Inc.  Embedded Web Technology   http://www.agranat.com/
Received on Friday, 10 September 1999 13:51:02 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:33:33 EDT