httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Kew <n...@webthing.com>
Subject Re: mod_proxy and interim responses
Date Thu, 04 Oct 2007 10:52:03 GMT
On Thu, 04 Oct 2007 11:27:30 +0200
Ruediger Pluem <rpluem@apache.org> wrote:

> I think you should move it to http_filters.c. There are a bunch
> of static functions that you can use for creating the header strings
> and all this stuff without reinventing the wheel.

Hmm.  It's only a one-line reinvention of a wheel.
I guess you mean things like ... AP_SERVER_PROTOCOL, " ",
     ap_get_status_line(100), CRLF CRLF, NULL);

> Furthermore ap_send_interim_response should not sent 100-Continue
> since this is already done by ap_http_filter.

That's dealing with the server itself responding to Expect.
It's Not Applicable to a 100 returned by a proxied backend
Nor an application module, which might want to use
ap_send_interim_response - e.g. to support Switching Protocols.

It's an edge-case, but RFC2616 seems fairly clear: we *can*
err on the side of sending superfluous interim responses,
but we *can't* eat them.

I think http_filters.c is dealing with automatic HTTP negotiation
controlled by the core, whereas ap_send_interim_response is an
API for applications (including proxy) and hence belongs in
protocol.c.  Unless you can convince me otherwise???


-- 
Nick Kew

Application Development with Apache - the Apache Modules Book
http://www.apachetutor.org/

Mime
View raw message