httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Plüm, Rüdiger, VF-Group" <>
Subject RE: trunk "ping" for http proxy
Date Mon, 16 Aug 2010 14:56:05 GMT

> -----Original Message-----
> From: Rainer Jung  
> Sent: Montag, 16. August 2010 16:40
> To:
> Subject: Re: trunk "ping" for http proxy
> On 16.08.2010 15:41, Jim Jagielski wrote:
> > As many know, one thing I've wanted in httpd's proxy for
> > http is a sort of pre-request ping option (ala what we
> > have for ajp) and nothing ever worked out fine, for a variety
> > of reasons.
> >
> > Anyway, I've gone back to an idea I had a long while ago
> > and one which ACO and Filip Hanik and I have played around
> > with and it's very simple: for backends which are http/1.1,
> > simply use a 100-Continue. If the backend is alive (and
> > compliant) we should semi-immediately continue with the
> > request, otherwise we can assume it's down (or so loaded
> > that it times out) and choose another backend.
> >
> > I'd like to get this in 2.3.7 before I T&R it, and it will
> > be optional behavior, not the default, but wanted to give
> > people a head's up beforehand.
> Two remarks:
> RFC 2616 says in "8.2.3 Use of the 100 (Continue) Status":
> ...
> Requirements for HTTP/1.1 clients:
> ...
>    - A client MUST NOT send an Expect request-header field (section
>      14.20) with the "100-continue" expectation if it does not intend
>      to send a request body.
> So if the proxy inserts an expectation for 100-continue by itself for 
> requests without bodies, it possibly is a violation of the spec. In 
> other words, it is unclear to me how other servers react on such an 
> expectation for requests without bodies. I'd say the benefit 
> still makes 
> the experiment worth it if configurable.
> The second remark:
> If the client already sends such an expectation, we must 
> forward it to 
> the origin server. In this case I guess we don't want to add a second 
> expect to the same request (and need to make sure we actually 
> return the 
> 100 to the client instead of only consuming it ourselves).

This basicly sums up the downsides of this approach I see as well.

IMHO to avoid a spec violation we can only add the Expect header to
requests with request bodies. OTOH these requests hurt most when they
fail as we cannot sent the request body for a second time, because
we do not have it any longer available in most situations and requests
with request bodies are usually not idempotent.

On the second issue we only need to take care that we do not add something
already there and remove something that client expects to see.

One last thing I see is that this only works if the backend is HTTP/1.1:


- If the proxy knows that the version of the next-hop server is HTTP/1.0 or lower
  , it MUST NOT forward the request and it MUST respond with a 417 (Expectation Failed)



View raw message