Open jocelyn opened 11 years ago
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.
Ok but obviously, we can also decide easily to use chunked or not
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?
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.
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.