EWF Make WSF_RESPONSE more user friendly / flexible : without content-length

Allow code to put content back to the client without specifying a content-length

On HTTP/1.1 this could be implemented using chunked encoding On HTTP/1.0 .. chunked encoding is not permitted, so we could buffer the content, and send everything including computed content-length when the request processing is done.

(i.e when the system call WGI_RESPONSE.push)

I guess this could be achieved using WGI_FILTER_RESPONSE.

Mar 13 '13 13:03 jocelyn

The easiest way with HTTP/1.0 is to insist on a proxy for HTTP/1.0 clients (respond with Use Proxy (305?)). Then you can just use chunked encoding.

Mar 22 '13 09:03 colin-adams

Ok but obviously, we can also decide easily to use chunked or not

Mar 22 '13 16:03 jocelyn

Sure. A handler that wants to use chunked encoding has two choices when faced with an HTTP/1.0 client - either respond with use_proxy, or don't use chunked encoding.

In the latter case, the content length is required. I think the handler just has to provide an alternative coding path. Or are you going to attempt to allow chunked encoding, and convert it to a non-chunked encoding in the filter?

Mar 22 '13 16:03 colin-adams

There is a third alternative, and that is to refuse connections from HTTP/1.0 clients. You might want to do this if you cannot run a proxy (because your service is not limited to an intranet - open proxies are considered a security risk). In which case you might respond with 505 HTTP Version Not Supported.

However the description of this response in the HTTP/1.1 spec. only talks about the major version. So it is probably not compliant to do this. So maybe your idea of using WGI_FILTER_RESPONSE is better.

Mar 23 '13 10:03 colin-adams