Are the built-in HTTP servers production quality?

Daniel Eloff danieleloff at hotmail.com
Mon Jul 19 21:56:18 CEST 2004


So buffer the entire file in memory. If the file is greater than a MB
(or what you deem as too much memory usage) then take the slower, two
passes through the file approach. (you shouldn't have to go very far on
the first pass to determine if the line endings are CRLF or just LF.)
You can always have your server convert the files to CRLF and write them
back out (might irritate some clients, but if you tell them it improves
server performance they won't complain. Maybe make this a
user-configurable option.)

-----Original Message-----
From: python-list-bounces+danieleloff=hotmail.com at python.org
[mailto:python-list-bounces+danieleloff=hotmail.com at python.org] On
Behalf Of Irmen de Jong
Sent: Monday, July 19, 2004 11:12 AM
To: python-list at python.org
Subject: Re: Are the built-in HTTP servers production quality?

Richard Brodie wrote:
> "Paul Morrow" <pm_mon at yahoo.com> wrote in message
> news:mailman.544.1090171663.5135.python-list at python.org...
> 
> 
>>I'm not sure that we can rely on the client browser doing the right
>>thing with the newlines.  I'm not aware of an rfc that really covers
>>this,
> 
> 
> HTTP 1.1 covers this topic:
> 
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7.1
> 
> Still, that doesn't help if your server text format isn't one of
these.

Hmm, well, reading that particular section of the HTTP spec makes
me think that the solution I programmed in the patch isn't the optimal
one.
Rather than treating text files (with content-type text/...) as any
other -binary- file, I now think that it's actually better to read them
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?


Bye,
Irmen.
-- 
http://mail.python.org/mailman/listinfo/python-list



More information about the Python-list mailing list