On Thu, 04 Oct 2007 11:27:30 +0200
Ruediger Pluem <[EMAIL PROTECTED]> 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/
