Fwd: url.el bug

[Michael Albinus <Michael.Albinus@alcatel-lucent.de>]

[-- Attachment #1: Type: text/plain, Size: 103 bytes --]

Hi,

could somebody, please, take over? I'm not so familiar with url-http.el.

Best regards, Michael.


[-- Attachment #2: Type: message/rfc822, Size: 3681 bytes --]

From: Damon Permezel <permezel@mac.com>
To: michael.albinus@gmx.de
Subject: url.el bug
Date: Thu, 6 Mar 2008 16:32:03 +1000
Message-ID: <C73672B3-CA61-4C56-8F62-512124A96C0B@mac.com>

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