Are the built-in HTTP servers production quality?

[Alan Kennedy]

[Irmen de Jong]
> in and convert the line endings to CR LF. But this requires:
> 
> - buffering of the entire text file in memory during the CR LF conversion
> - fixing the content-type at the end because it's not the same as
>   the filesize (this was the original problem I solved).
> 
> What do you think?

Or send it with "Transfer-encoding: chunked", which is purpose built 
for dealing with content of unknown length.

http://www.cse.ohio-state.edu/cgi-bin/rfc/rfc2616.html#sec-3.6.1

Each chunk is preceded by a header indicating the size of the 
forthcoming chunk. An algorithm for reading chunked encoding is given 
in one of the appendices: it's pretty simple to understand:-

http://www.cse.ohio-state.edu/cgi-bin/rfc/rfc2616.html#sec-19.4.6

So on the server side, simply continually buffer as much of the 
textual content as you want to send in each chunk, do your 
line-endings translation on the buffer, send an ascii rep of the size 
of the buffer, and then send the buffer contents. Repeat until EOF.

This is how robust production servers like Apache and Tomcat do it: 
they don't try to buffer the content, for a whole load of good reasons.

Each chunk can also have its own separate headers, which are appended 
to the headers for the whole response, while processing that chunk, so 
it should be relatively simple to do "Transfer-encoding: gzip" on each 
chunk as well, for that extra bandwith saving.

Just one more way to do it.

-- 
alan kennedy
------------------------------------------------------
check http headers here: http://xhaus.com/headers
email alan:              http://xhaus.com/contact/alan