[ python-Bugs-1097597 ] SimpleHTTPServer sends wrong Content-Length header
Bugs item #1097597, was opened at 2005-01-06 18:34
Message generated for change (Comment added) made by josiahcarlson
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1097597&group_id=5470
Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: David Schachter (razmatazz)
Assigned to: Nobody/Anonymous (nobody)
Summary: SimpleHTTPServer sends wrong Content-Length header
Initial Comment:
On Microsoft Windows, text files use \r\n for newline.
The SimpleHTTPServer class's "send_head()" method opens
files with "r" or "rb" mode depending on the MIME type.
Files opened in "r" mode will have \r\n -> \n
translation performed automatically, so the stream of
bytes sent to the client will be smaller than the size
of the file on disk.
Unfortunately, the send_head() method sets the
Content-Length header using the file size on disk,
without compensating for the \r\n -> \n translation.
I remedied this on my copy thusly:
if mode == "r":
content = f.read()
contentLength = str(len(content))
f.seek(0)
else:
contentLength = str(os.fstat(f.fileno())[6])
self.send_header("Content-Length", contentLength)
This may not be as inefficient as it seems: the entire
file was going to be read in anyway for the newline
translation.
Hmmm. The code could be slightly simpler:
if mode == "r":
contentLength = len(f.read())
f.seek(0)
else:
contentLength = os.fstat(f.fileno())[6]
self.send_header("Content-Length",
str(contentLength))
The documentation for SimpleHTTPServer in Python 2.3.4
for Windows says:
A 'Content-type:' with the guessed content type is
output, and then a blank line, signifying end of
headers, and then the contents of the file. The file
is always opened in binary mode.
Actually, after Content-type, the Content-Length header
is sent.
It would probably be nice if "Content-Length" was
"Content-length" or if "Content-type" was
"Content-Type", for consistency. The latter is probably
best, per RFC 2016.
By the way, clients weren't caching the files I sent. I
added another line after the Content-Length handling:
self.send_header("Expires", "Fri, 31 Dec 2100
12:00:00 GMT")
This is egregiously wrong in the general case and just
fine in my case.
--
Comment By: Josiah Carlson (josiahcarlson)
Date: 2005-01-09 01:26
Message:
Logged In: YES
user_id=341410
Would it be wrong to open all files with a mode of 'rb',
regardless of file type?
While I don't know MIME embeddings all that well, I do have
experience with email and that most codecs that use MIME
embeddings (like base 64, 85, 95, etc.) are \r, \n and \r\n
agnostic..
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1097597&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1093173 ] distutils/tests not installed
Bugs item #1093173, was opened at 2004-12-30 09:43 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1093173&group_id=5470 Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: distutils/tests not installed Initial Comment: The new subdirectory distutils/tests is not copied to the installation location by a 'make install'. This causes test_distutils to crash when run from an installed path (as opposed to from a CVS check-out). I could propose a patch (Makefile.pre.in) given some bash syntax learning efforts -- for example, distutils/tests shouldn't be installed if we want a no-test installation. This raises the question about why distutils/tests isn't actually called test/distutils... -- >Comment By: Armin Rigo (arigo) Date: 2005-01-09 13:53 Message: Logged In: YES user_id=4771 Patch attached. -- Comment By: Martin v. Löwis (loewis) Date: 2004-12-30 14:11 Message: Logged In: YES user_id=21627 Please do try to come up with a patch. I'm not sure I understand the no-test business - there is no no-test installation AFAICT; adding it to LIBSUBDIRS might be sufficient. The Windows installer has the notion of no-test installs; it did always package distutils/tests, but now also conditionalizes installation on the selection of the testsuite. As for choice of location of the tests: both bsddb and email have their own test directories, both because they contain a large number of tests, and because they are both packaged independently of Python. The same could be said about distutils. As for the choice of name: it is called "test" in all other cases, only "tests" for distutils. This is unfortunate, but changing directories in CVS does more harm than good. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1093173&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1093173 ] distutils/tests not installed
Bugs item #1093173, was opened at 2004-12-30 09:43 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1093173&group_id=5470 Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: distutils/tests not installed Initial Comment: The new subdirectory distutils/tests is not copied to the installation location by a 'make install'. This causes test_distutils to crash when run from an installed path (as opposed to from a CVS check-out). I could propose a patch (Makefile.pre.in) given some bash syntax learning efforts -- for example, distutils/tests shouldn't be installed if we want a no-test installation. This raises the question about why distutils/tests isn't actually called test/distutils... -- >Comment By: Armin Rigo (arigo) Date: 2005-01-09 13:55 Message: Logged In: YES user_id=4771 Patch attached. -- Comment By: Armin Rigo (arigo) Date: 2005-01-09 13:53 Message: Logged In: YES user_id=4771 Patch attached. -- Comment By: Martin v. Löwis (loewis) Date: 2004-12-30 14:11 Message: Logged In: YES user_id=21627 Please do try to come up with a patch. I'm not sure I understand the no-test business - there is no no-test installation AFAICT; adding it to LIBSUBDIRS might be sufficient. The Windows installer has the notion of no-test installs; it did always package distutils/tests, but now also conditionalizes installation on the selection of the testsuite. As for choice of location of the tests: both bsddb and email have their own test directories, both because they contain a large number of tests, and because they are both packaged independently of Python. The same could be said about distutils. As for the choice of name: it is called "test" in all other cases, only "tests" for distutils. This is unfortunate, but changing directories in CVS does more harm than good. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1093173&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1093173 ] distutils/tests not installed
Bugs item #1093173, was opened at 2004-12-30 09:43 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1093173&group_id=5470 Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: distutils/tests not installed Initial Comment: The new subdirectory distutils/tests is not copied to the installation location by a 'make install'. This causes test_distutils to crash when run from an installed path (as opposed to from a CVS check-out). I could propose a patch (Makefile.pre.in) given some bash syntax learning efforts -- for example, distutils/tests shouldn't be installed if we want a no-test installation. This raises the question about why distutils/tests isn't actually called test/distutils... -- >Comment By: Armin Rigo (arigo) Date: 2005-01-09 14:03 Message: Logged In: YES user_id=4771 Attachment was corrupted?? Second try... -- Comment By: Armin Rigo (arigo) Date: 2005-01-09 13:55 Message: Logged In: YES user_id=4771 Patch attached. -- Comment By: Armin Rigo (arigo) Date: 2005-01-09 13:53 Message: Logged In: YES user_id=4771 Patch attached. -- Comment By: Martin v. Löwis (loewis) Date: 2004-12-30 14:11 Message: Logged In: YES user_id=21627 Please do try to come up with a patch. I'm not sure I understand the no-test business - there is no no-test installation AFAICT; adding it to LIBSUBDIRS might be sufficient. The Windows installer has the notion of no-test installs; it did always package distutils/tests, but now also conditionalizes installation on the selection of the testsuite. As for choice of location of the tests: both bsddb and email have their own test directories, both because they contain a large number of tests, and because they are both packaged independently of Python. The same could be said about distutils. As for the choice of name: it is called "test" in all other cases, only "tests" for distutils. This is unfortunate, but changing directories in CVS does more harm than good. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1093173&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-994101 ] urllib2: improper capitalization of headers
Bugs item #994101, was opened at 2004-07-19 23:22 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994101&group_id=5470 Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Robert Sayre (franklinmint) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2: improper capitalization of headers Initial Comment: urllib2.py version 1.72 uses capitalize() on HTTP header names. This results in headers like "User-agent" instead of "User-Agent". This causes HTTP 400 errors on some servers when the request has a body, because there are two content length headers placed in the request: "Content-Length" (inserted by httplib) "Content-length" (inserted by Request.add_unredirected_header) The capitalization is incorrect, and httplib inserts Content-Length anyway, so I'm not sure why urllib2 is bothering. -- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-01-09 15:56 Message: Logged In: YES user_id=469548 This was fixed by the new patch jjlee provided (#997626). -- Comment By: John J Lee (jjlee) Date: 2004-07-25 20:06 Message: Logged In: YES user_id=261020 I've added a comment to 996159 which explains what's wrong and points to a new patch. -- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-07-22 22:48 Message: Logged In: YES user_id=469548 Patch is available at http://python.org/sf/996159. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=994101&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-548176 ] urlparse doesn't handle host?bla
Bugs item #548176, was opened at 2002-04-24 17:36 Message generated for change (Comment added) made by jlgijsbers You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=548176&group_id=5470 Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Markus Demleitner (msdemlei) Assigned to: Nobody/Anonymous (nobody) Summary: urlparse doesn't handle host?bla Initial Comment: The urlparse module (at least in 2.2 and 2.1, Linux) doesn't handle URLs of the form http://www.maerkischeallgemeine.de?loc_id=49 correctly -- everything up to the 9 ends up in the host. I didn't check the RFC, but in the real world URLs like this do show up. urlparse works fine when there's a trailing slash on the host name: http://www.maerkischeallgemeine.de/?loc_id=49 Example:>>> import urlparse >>> urlparse.urlparse("http://www.maerkischeallgemeine.de/?loc_id=49";) ('http', 'www.maerkischeallgemeine.de', '/', '', 'loc_id=49', '') >>> urlparse.urlparse("http://www.maerkischeallgemeine.de?loc_id=49";) ('http', 'www.maerkischeallgemeine.de?loc_id=49', '', '', '', '')This has serious implications for urllib, since urllib.urlopen will fail for URLs like the second one, and with a pretty mysterious exception ("host not found") at that. -- >Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-01-09 16:33 Message: Logged In: YES user_id=469548 Fixed by applying patch #712317 on maint24 and HEAD. -- Comment By: Paul Moore (pmoore) Date: 2004-11-08 21:48 Message: Logged In: YES user_id=113328 This issue still exists in Python 2.3.4 and Python 2.4b2. -- Comment By: Mike Rovner (mrovner) Date: 2004-10-23 09:44 Message: Logged In: YES user_id=162094 I'm sorry, I misunderstood the patch. If it accepts such URL and split it at '?', it's perfectly fine. It shall not reject such URL as malformed. -- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2004-10-23 09:03 Message: Logged In: YES user_id=469548 Somehow I think I'm missing something. Please check my line of reasoning: 1. http://foo?bar=baz is a legal URL. 2. urlparse's 'Network location' should be the same as from rfc2396. 3. Inside an unescaped '?' is not allowed. Rather: is terminated by the '?'. 4. Currently the 'network location' for http://foo?bar=baz would be 'foo?bar=baz. 5. If 'network location' should be the same as , it should also be terminated by the '?'. So shouldn't urlparse.urlsplit('http://foo?bar=baz') return ('http', 'foo', '', '', 'bar=baz', ''), as patch 712317 implements? -- Comment By: Mike Rovner (mrovner) Date: 2004-01-27 02:13 Message: Logged In: YES user_id=162094 According to RFC2396 (ftp://ftp.isi.edu/in-notes/rfc2396.txt) absoluteURI (part 3 URI Syntactic Components) can be: """ ://? each of which, except , may be absent from a particular URI. """ Later on (3.2): """ The authority component is preceded by a double slash "//" and is terminated by the next slash "/", question-mark "?", or by the end of the URI. """ So URL "http://server?query"; is perfectly legal and shall be allowed and patch 712317 rejected. -- Comment By: Steven Taschuk (staschuk) Date: 2003-03-30 22:19 Message: Logged In: YES user_id=666873 For comparison, RFC 1738 section 3.3: An HTTP URL takes the form: http://: / ? ; [...] If neither nor is present, the "/" may also be omitted. ... which does not outright say the '/' may *not* be omitted if is absent but is present (though imho that's implied). But even if the / may not be omitted in this case, ? is not allowed in the authority component under either RFC 2396 or RFC 1738, so urlparse should either treat it as a delimiter or reject the URL as malformed. The principle of being lenient in what you accept favours the former. I've just submitted a patch (712317) for this. -- Comment By: Jeff Epler (jepler) Date: 2002-11-17 17:56 Message: Logged In: YES user_id=2772 This actually appears to be permitted by RFC2396 [http://www.ietf.org/rfc/rfc2396.txt]. See section 3.2: 3.2. Authority Component Many URI schemes include a top hierarchical element for a naming authority, such that the namespace defined by the remainder of the URI is governed by that authority. This authority component is typically defined by an Internet-based server or a scheme-specific registry of naming authorities. authority = server | reg_name The authori
[ python-Bugs-1098985 ] set objects cannot be marshalled
Bugs item #1098985, was opened at 2005-01-09 11:28 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1098985&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Gregory H. Ball (greg_ball) Assigned to: Nobody/Anonymous (nobody) Summary: set objects cannot be marshalled Initial Comment: It would be nice if set objects could be marshalled. This would require extra code in marshal.c very similar to that for dictionaries. Since sets can be pickled I guess this is not critical. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1098985&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1098990 ] codec readline() splits lines apart
Bugs item #1098990, was opened at 2005-01-09 17:45 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1098990&group_id=5470 Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Irmen de Jong (irmen) Assigned to: Nobody/Anonymous (nobody) Summary: codec readline() splits lines apart Initial Comment: It seems that the fix for bug 1076985 (Incorrect behaviour of StreamReader.readline leads to crash) has introduced a new bug. using current cvs Python on Linux, I observe faulty behavior of the readline() method on file-like objects returned from the codecs module. See the attached example.txt. The readline() breaks certain lines in half. It only happens when a certain encoding is used, so regular file objects behave as expected. Also, readlines() works fine. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1098990&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1095821 ] The doc for DictProxy is missing
Bugs item #1095821, was opened at 2005-01-04 10:42 Message generated for change (Comment added) made by greg_ball You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1095821&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Colin J. Williams (cjwhrh) Assigned to: Nobody/Anonymous (nobody) Summary: The doc for DictProxy is missing Initial Comment: The types module has an entry for DictProxy. I am unable to find any documentation. -- Comment By: Gregory H. Ball (greg_ball) Date: 2005-01-09 11:48 Message: Logged In: YES user_id=11365 DictProxy is an implementation detail, perhaps it should have been left out of types. I notice there is no CellType in there. (you can obtain this type like so:) >>> type((lambda x: lambda: x)(1).func_closure[0]) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1095821&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1097597 ] SimpleHTTPServer sends wrong Content-Length header
Bugs item #1097597, was opened at 2005-01-07 03:34
Message generated for change (Comment added) made by jlgijsbers
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1097597&group_id=5470
Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: David Schachter (razmatazz)
Assigned to: Nobody/Anonymous (nobody)
Summary: SimpleHTTPServer sends wrong Content-Length header
Initial Comment:
On Microsoft Windows, text files use \r\n for newline.
The SimpleHTTPServer class's "send_head()" method opens
files with "r" or "rb" mode depending on the MIME type.
Files opened in "r" mode will have \r\n -> \n
translation performed automatically, so the stream of
bytes sent to the client will be smaller than the size
of the file on disk.
Unfortunately, the send_head() method sets the
Content-Length header using the file size on disk,
without compensating for the \r\n -> \n translation.
I remedied this on my copy thusly:
if mode == "r":
content = f.read()
contentLength = str(len(content))
f.seek(0)
else:
contentLength = str(os.fstat(f.fileno())[6])
self.send_header("Content-Length", contentLength)
This may not be as inefficient as it seems: the entire
file was going to be read in anyway for the newline
translation.
Hmmm. The code could be slightly simpler:
if mode == "r":
contentLength = len(f.read())
f.seek(0)
else:
contentLength = os.fstat(f.fileno())[6]
self.send_header("Content-Length",
str(contentLength))
The documentation for SimpleHTTPServer in Python 2.3.4
for Windows says:
A 'Content-type:' with the guessed content type is
output, and then a blank line, signifying end of
headers, and then the contents of the file. The file
is always opened in binary mode.
Actually, after Content-type, the Content-Length header
is sent.
It would probably be nice if "Content-Length" was
"Content-length" or if "Content-type" was
"Content-Type", for consistency. The latter is probably
best, per RFC 2016.
By the way, clients weren't caching the files I sent. I
added another line after the Content-Length handling:
self.send_header("Expires", "Fri, 31 Dec 2100
12:00:00 GMT")
This is egregiously wrong in the general case and just
fine in my case.
--
>Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2005-01-09 18:18
Message:
Logged In: YES
user_id=469548
http://python.org/sf/839496 has a patch for this, but the
submitter isn't sure whetther it's correct. Maybe one of you
could take a look at it?
--
Comment By: Josiah Carlson (josiahcarlson)
Date: 2005-01-09 10:26
Message:
Logged In: YES
user_id=341410
Would it be wrong to open all files with a mode of 'rb',
regardless of file type?
While I don't know MIME embeddings all that well, I do have
experience with email and that most codecs that use MIME
embeddings (like base 64, 85, 95, etc.) are \r, \n and \r\n
agnostic..
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1097597&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1098985 ] set objects cannot be marshalled
Bugs item #1098985, was opened at 2005-01-09 11:28 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1098985&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Gregory H. Ball (greg_ball) >Assigned to: Raymond Hettinger (rhettinger) Summary: set objects cannot be marshalled Initial Comment: It would be nice if set objects could be marshalled. This would require extra code in marshal.c very similar to that for dictionaries. Since sets can be pickled I guess this is not critical. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1098985&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1097597 ] SimpleHTTPServer sends wrong Content-Length header
Bugs item #1097597, was opened at 2005-01-07 03:34
Message generated for change (Comment added) made by irmen
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1097597&group_id=5470
Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: David Schachter (razmatazz)
Assigned to: Nobody/Anonymous (nobody)
Summary: SimpleHTTPServer sends wrong Content-Length header
Initial Comment:
On Microsoft Windows, text files use \r\n for newline.
The SimpleHTTPServer class's "send_head()" method opens
files with "r" or "rb" mode depending on the MIME type.
Files opened in "r" mode will have \r\n -> \n
translation performed automatically, so the stream of
bytes sent to the client will be smaller than the size
of the file on disk.
Unfortunately, the send_head() method sets the
Content-Length header using the file size on disk,
without compensating for the \r\n -> \n translation.
I remedied this on my copy thusly:
if mode == "r":
content = f.read()
contentLength = str(len(content))
f.seek(0)
else:
contentLength = str(os.fstat(f.fileno())[6])
self.send_header("Content-Length", contentLength)
This may not be as inefficient as it seems: the entire
file was going to be read in anyway for the newline
translation.
Hmmm. The code could be slightly simpler:
if mode == "r":
contentLength = len(f.read())
f.seek(0)
else:
contentLength = os.fstat(f.fileno())[6]
self.send_header("Content-Length",
str(contentLength))
The documentation for SimpleHTTPServer in Python 2.3.4
for Windows says:
A 'Content-type:' with the guessed content type is
output, and then a blank line, signifying end of
headers, and then the contents of the file. The file
is always opened in binary mode.
Actually, after Content-type, the Content-Length header
is sent.
It would probably be nice if "Content-Length" was
"Content-length" or if "Content-type" was
"Content-Type", for consistency. The latter is probably
best, per RFC 2016.
By the way, clients weren't caching the files I sent. I
added another line after the Content-Length handling:
self.send_header("Expires", "Fri, 31 Dec 2100
12:00:00 GMT")
This is egregiously wrong in the general case and just
fine in my case.
--
Comment By: Irmen de Jong (irmen)
Date: 2005-01-10 01:49
Message:
Logged In: YES
user_id=129426
http://sourceforge.net/support/tracker.php?aid=839496 is a
better url because it has been moved.
I've added a comment to my patch, because I'm now quite sure
it is good after all.
--
Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2005-01-09 18:18
Message:
Logged In: YES
user_id=469548
http://python.org/sf/839496 has a patch for this, but the
submitter isn't sure whetther it's correct. Maybe one of you
could take a look at it?
--
Comment By: Josiah Carlson (josiahcarlson)
Date: 2005-01-09 10:26
Message:
Logged In: YES
user_id=341410
Would it be wrong to open all files with a mode of 'rb',
regardless of file type?
While I don't know MIME embeddings all that well, I do have
experience with email and that most codecs that use MIME
embeddings (like base 64, 85, 95, etc.) are \r, \n and \r\n
agnostic..
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1097597&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1095821 ] The doc for DictProxy is missing
Bugs item #1095821, was opened at 2005-01-04 10:42 Message generated for change (Comment added) made by cjwhrh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1095821&group_id=5470 Category: Python Library Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Colin J. Williams (cjwhrh) Assigned to: Nobody/Anonymous (nobody) Summary: The doc for DictProxy is missing Initial Comment: The types module has an entry for DictProxy. I am unable to find any documentation. -- >Comment By: Colin J. Williams (cjwhrh) Date: 2005-01-09 21:09 Message: Logged In: YES user_id=285587 I suggest that it would be better to indicate the purpose and usage of both CellType in the Library Reference. If one is to keep it under the pillow, it should be complete and uptodate. Colin W. -- Comment By: Gregory H. Ball (greg_ball) Date: 2005-01-09 11:48 Message: Logged In: YES user_id=11365 DictProxy is an implementation detail, perhaps it should have been left out of types. I notice there is no CellType in there. (you can obtain this type like so:) >>> type((lambda x: lambda: x)(1).func_closure[0]) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1095821&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-489256 ] Lib/profile.doc should be updated
Bugs item #489256, was opened at 2001-12-05 00:51 Message generated for change (Comment added) made by fdrake You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=489256&group_id=5470\\ Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Johannes Gijsbers (jlgijsbers) Summary: Lib/profile.doc should be updated Initial Comment: What's Lib/profile.doc doing there? Is it still needed? Why is it in Lib, anyway? (it seems very old - is it still up to date after all the hackery? doesn't seem so) -- >Comment By: Fred L. Drake, Jr. (fdrake) Date: 2005-01-09 22:07 Message: Logged In: YES user_id=3066 Removing profile.doc sounds fine to me. The only thing that really needs to be done prior to removal is to make sure all the (still current) information in profile.doc is represented in the library documentation. The help() function should probably be replaced with something that refers the user to the library documentation, rather than removing the function. -- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-01-08 20:27 Message: Logged In: YES user_id=469548 I would like to go ahead with removing profile.doc and the help() function from profile.py for Python 2.5. They're not really all that helpful, they're in an unexpected place, and they're undocumented. I'll remove them if there are no objections within some weeks. -- Comment By: Fred L. Drake, Jr. (fdrake) Date: 2001-12-05 01:08 Message: Logged In: YES user_id=3066 profile.doc is used as the help file for profile.py, and is read by an external pager (sloppily) using the profile.help() function. Either the document should be updated and the help() function should be more intelligent about the pager, or... ...the document and the help() function should be removed. This is a possibility since help() is not documented. profile.doc should be updated for Python 2.2; other changes will need to wait for Python 2.3. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=489256&group_id=5470\\ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-756982 ] mailbox should use email not rfc822
Bugs item #756982, was opened at 2003-06-19 12:19 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=756982&group_id=5470 Category: Extension Modules Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Ben Leslie (benno37) Assigned to: Barry A. Warsaw (bwarsaw) Summary: mailbox should use email not rfc822 Initial Comment: The mailbox module uses the rfc822 module as its default factory for creating message objects. The rfc822 documentation claims that its use is deprecated. The mailbox module should probably use the new email module as its default factory. Of course this has backward compatibility issues, in which case it should at least be mentioned in the mailbox documentation that it uses the deprecated rfc822 module, and provide an example of how to use the email module instead. -- >Comment By: Anthony Baxter (anthonybaxter) Date: 2005-01-10 18:56 Message: Logged In: YES user_id=29957 Given the amount of code out there using rfc822, should we instead PDW it? In any case, I'm -0 on putting a DeprecationWarning on it unless we've removed all use of it from the stdlib. -- Comment By: Barry A. Warsaw (bwarsaw) Date: 2005-01-09 02:49 Message: Logged In: YES user_id=12800 It's a good question. I'd like to say yes so that we can start adding deprecation warnings to rfc822 for Python 2.5. -- Comment By: Johannes Gijsbers (jlgijsbers) Date: 2005-01-09 01:22 Message: Logged In: YES user_id=469548 So, with the plans to seriously start working deprecating rfc822, should we use the email module as the default factory now? -- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-06-21 07:48 Message: Logged In: YES user_id=12800 I've added some sample code to the mailbox documentation that explain how to use the email package with the mailbox module. We can't change the default for backward compatibility reasons, as you point out. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=756982&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
