--- Begin Message ---
|
Subject: |
url.el bug |
|
Date: |
Thu, 6 Mar 2008 16:32:03 +1000 |
Hi.
I was using url.el to download some stuff from the emacs wiki. All
the files came over with a trailing, final ^M appended at the and of
the file.
Not on every line, just at the EOF.
Tacked it down to a transfer-encoding: chunked issue. Must be an off-
by-one.
Turned on HTTP/1.0 only mode, and works a treat.
Used command line 'curl' to fetch, and I actually can't remember if it
did chunked, but if worked. Ok, that is not very useful.
I verified the on-the-wire bytes that the trailing CR was not part of
the data, but did assume that the initial byte count was correct. Ok,
also not very useful.
Here is the final few bytes from wireshark:
00039814 3b 3b 3b 3b 3b 3b 3b 3b 3b 3b 3b 3b 3b 3b 0a
3b ;;;;;;;; ;;;;;;.;
00039824 3b 3b 20 69 63 69 63 6c 65 73 2d 64 6f 63 31 2e ;; icicl es-
doc1.
00039834 65 6c 20 65 6e 64 73 20 68 65 72 65 0a 0d 0a 30 el ends
here...0
00039844 0d 0a 0d 0a ....
We see 'ends here\n\r\n0\r\n\r\n'
The '0\r\n\r\n' is because of the HTTP Transfer-Encoding: chunked.
This indicates that the next chunk has size of 0, which is per the spec.
chunk = chunk-size [ chunk-extension ] CRLF chunk-data CRLF
so the 'here\n' is the (end of the) chunk-data and the '\r\n' is the
CRLF then.
Looks like I have version 1.57.
MD5 (url-http.el) = ba5a2f747e0236f5207c89bb180c9d12
MD5 (/Applications/Emacs.app/Contents/Resources/lisp/url/url-http.el)
= ba5a2f747e0236f5207c89bb180c9d12
=dap
--- End Message ---