(Python 2.3.2 on Windows)

SimpleHTTPServer reports the size of the file on disk
as Content-Length. This works except for text files.
If the content type starts with "text/" it is opening the
file in 'text' mode rather than 'binary' mode. At least on
Windows this causes newline translations, thereby making
the  actual size of the content transmitted *less* than
the content-length!

I don't know why SimpleHTTPServer is reading text files
with text mode. The included patch removes this distinction
so all files are opened in binary mode (and, also on
windows,
the actual size transmitted is the same as the reported
content-length).

--Irmen de Jong

Logged In: YES 
user_id=129426

This bug is also still present in the SimpleHTTPServer.py
from Python 2.3.3 (and in the current CVS version, too).

Is there a reason why it treats text files differently? If
so, then at least the reported content-length must be fixed.

Logged In: YES 
user_id=129426

The attached trivial patch removes the special case for text
files.

Logged In: YES 
user_id=129426

The attached httptest.zip contains a test scenario. When run
on windows, it will show the problem.
First start 'startserver.py' and then from the same
directory run test.py.
I get this:

[E:\temp\httptest]python test.py
The reported content-length is: 1047 bytes
The real filesize is: 1047 bytes
The data I actually received from the httpserver is: 1028 bytes

Logged In: YES 
user_id=129426

Hm, perhaps the easy way out (see my patch) is not the best
solution:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.7.1

It seems it's best to convert text responses to CR LF
format? If we should do this, we must somehow 're-calculate'
the content-length after the CR LF conversion.

Logged In: YES 
user_id=129426

Upon re-reading the w3 spec, it seems that we're safe. As
long as the use of CR or LF or CR+LF is consistent in the
whole text file.
The spec says: "HTTP relaxes this requirement [=the
requirement of being in canonical form] and allows the
transport of text media with plain CR or LF alone
representing a line break when it is done consistently for
an entire entity-body. HTTP applications MUST accept CRLF,
bare CR, and bare LF as being representative of a line break
in text media received via HTTP."

So my patch is safe, I think.

Logged In: YES 
user_id=469548

Okay, I've checked in the fix on maint24 and HEAD.

As noted by Leo Jay in this message 
<http://mail.python.org/pipermail/python-list/2008-June/495718.html>
this bug was supposedly fixed but it is still present.

Looks like the patch was only applied to release24-maint, not to the 
trunk. Both the 2.5 and the 2.6 sources don't have the patch applied. 
3.0 doesn't have this problem but probably it was fixed independently.

I confirm that the problem is present on python2.5 on windows, and that
the attached patch fixes it.

Committed as r64762.
Maybe a 2.5 backport candidate, but I fear that it may break existing code.

Better not to backport it then.