From unknown Mon Jun 16 23:39:38 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#16220 <16220@debbugs.gnu.org> To: bug#16220 <16220@debbugs.gnu.org> Subject: Status: url-http.el: Not conforming to HTTP spec Reply-To: bug#16220 <16220@debbugs.gnu.org> Date: Tue, 17 Jun 2025 06:39:38 +0000 retitle 16220 url-http.el: Not conforming to HTTP spec reassign 16220 emacs submitter 16220 Jaros=C5=82aw Rzesz=C3=B3tko severity 16220 normal tag 16220 patch thanks From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 22 15:52:36 2013 Received: (at submit) by debbugs.gnu.org; 22 Dec 2013 20:52:36 +0000 Received: from localhost ([127.0.0.1]:34909 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Vuq0p-0000UU-RX for submit@debbugs.gnu.org; Sun, 22 Dec 2013 15:52:36 -0500 Received: from eggs.gnu.org ([208.118.235.92]:50994) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Vuq0m-0000UG-GS for submit@debbugs.gnu.org; Sun, 22 Dec 2013 15:52:33 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vuq0k-0001mq-Ih for submit@debbugs.gnu.org; Sun, 22 Dec 2013 15:52:31 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM, HTML_MESSAGE,T_DKIM_INVALID autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:58543) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vuq0k-0001mm-Fv for submit@debbugs.gnu.org; Sun, 22 Dec 2013 15:52:30 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52710) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vuq0i-0000A1-Vp for bug-gnu-emacs@gnu.org; Sun, 22 Dec 2013 15:52:30 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vuq0e-0001is-QO for bug-gnu-emacs@gnu.org; Sun, 22 Dec 2013 15:52:28 -0500 Received: from mail-pd0-x236.google.com ([2607:f8b0:400e:c02::236]:58670) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vuq0e-0001g6-EJ for bug-gnu-emacs@gnu.org; Sun, 22 Dec 2013 15:52:24 -0500 Received: by mail-pd0-f182.google.com with SMTP id v10so4437533pde.41 for ; Sun, 22 Dec 2013 12:52:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=3ov+rdqcAXD+gs/CbbH6F7tVL+MxLA93Cb0eIH7pAT8=; b=i45s1f4Evsq1N/WsiVYJXVj0o6o+6TekIgBHge0Y0Q49ThXlwNAWLu1DkhNrx3JooU EFtJjPEg11Rn4fvhvFksjvzDro1XGb0LEdnOC1aPnOCBuI7tmRCgzozm7DWNdqZ5c6Fp jknVGLbmMbOtUr0GPgLS1UiUKZY/7AD7yDgL787JJ3ZLH5AA6yq5aKuX91lO3kQn8z0Q kSMifovtBWIUAVIcQAjYiFKNLN+xBl7EPZuVpQx6JUEyDTq4wS7+al654MgWcJkIK+ws GSz62ztlwGEltd8LAAjjmXECpBkWwF19tEa+LPHk2P1lWtQxJrPe3RsCHC8m8rcB8tfS Oajw== MIME-Version: 1.0 X-Received: by 10.66.168.12 with SMTP id zs12mr22232651pab.122.1387745542881; Sun, 22 Dec 2013 12:52:22 -0800 (PST) Received: by 10.66.77.230 with HTTP; Sun, 22 Dec 2013 12:52:22 -0800 (PST) Date: Sun, 22 Dec 2013 21:52:22 +0100 Message-ID: Subject: url-http.el: Not conforming to HTTP spec From: =?ISO-8859-2?Q?Jaros=B3aw_Rzesz=F3tko?= To: bug-gnu-emacs@gnu.org Content-Type: multipart/alternative; boundary=047d7bdc7c881f476f04ee25b0f4 X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.0 (----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.0 (----) --047d7bdc7c881f476f04ee25b0f4 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable Hi, At the end of every HTTP request to be made with url-http.el and containing a body, an unnecessary "\r\n" is appended, and additionally those two characters are not used in the calculation of the Content-Length header. This normally would not matter, because a carefully build server will anyway only read "Content-Length" bytes from the body and ignore the final CRLF, but Emacs additionally defaults to using Connection: keep-alive, which results in the TCP traffic for what was meant to be a single request, being interpreted as two separate HTTP requests, the first one being roughly the intended one, and the other one consisting only of CRLF. In particular, I am using the HTTP server from net.http in Go language. That keepalive is enabled by default is strange, especially given how the variable that controls this is described: (defvar url-http-attempt-keepalives t "Whether to use a single TCP connection multiple times in HTTP. This is only useful when debugging the HTTP subsystem. Setting to nil will explicitly close the connection to the server after every request.") Those issues have been somewhat discussed here, but it seems the people discussing unfortunately don't understand HTTP: https://groups.google.com/forum/#!msg/gnu.emacs.bug/SF4P7gVI6IQ/SExtWzutKI4= J Please just compare this discussion to http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html If you don't go into any fancy things like chunked encoding etc., an HTTP request is a: - sequence of headers, each header followed with a newline - a newline terminating the sequence of headers - an optional request body The request body will be read by the server only if one of the headers is a Content-Length header, and the value of the header is exactly the number of bytes that is being sent, there is no CRLF terminating the body. So if there is no body, the request ends with two CRLFs, if there is a body, it just ends with [Content-Length] bytes of raw data. There is no possibility a proper HTTP server could be confused by a request being terminated with two CRLFs, if the request is otherwise correct. I think there must have been some confusion as to the reason of the original problem, that was then turned into this "fix". For reference, my code is roughly this, and as mentioned I am using net.http from the Go language on the other end: (defun server-command (command) (let* ((url-request-method "POST") (url-request-extra-headers '(("Content-Type" . "application/x-www-form-urlencoded"))) (url-request-data (concat (url-hexify-string "command") "=3D" (url-hexify-string (json-encode command)))) (result-buffer (url-retrieve-synchronously server-url)) (result (with-current-buffer result-buffer (goto-char (point-min)) (delete-region (point-min) (search-forward "\n\n")) (buffer-string)))) (kill-buffer result-buffer) result)) Normally I get from this function the contents of the first, "correct" response body from the server, but if I run it a few times in quick succession I additonally get the string "HTTP/1.1 400 Bad Request" at the end, which is actually the second HTTP response showing up at random in the buffer (altough it's consistently sent by the server every time, as I can see in a sniffer). Cheers, Jaros=B3aw Rzesz=F3tko --047d7bdc7c881f476f04ee25b0f4 Content-Type: text/html; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable
Hi,

At the end of every HTTP request to b= e made with url-http.el and containing a body, an unnecessary "\r\n&qu= ot; is appended, and additionally those two characters are not used in the = calculation of the Content-Length header. This normally would not matter, b= ecause a carefully build server will anyway only read "Content-Length&= quot; bytes from the body and ignore the final CRLF, but Emacs additionally= defaults to using Connection: keep-alive, which results in the TCP traffic= for what was meant to be a single request, being interpreted as two separa= te HTTP requests, the first one being roughly the intended one, and the oth= er one consisting only of CRLF. In particular, I am using the HTTP server f= rom net.http in Go language. That keepalive is enabled by default is strang= e, especially given how the variable that controls this is described:

(defvar url-http-attempt-keepalives t
=A0 "Whether to use = a single TCP connection multiple times in HTTP.
This is only useful when= debugging the HTTP subsystem.=A0 Setting to
nil will explicitly close t= he connection to the server after every
request.")

Those issues have been somewhat discussed here= , but it seems the people discussing unfortunately don't understand HTT= P:

https://groups.google.com/forum/#!msg/gnu.emacs.bug= /SF4P7gVI6IQ/SExtWzutKI4J

Please just compare this discussion to http://www.w3.org/Protocols/rf= c2616/rfc2616-sec4.html

If you don't go into any fancy thin= gs like chunked encoding etc., an HTTP request is a:

- sequence of headers, each header followed with a newline
- a newline terminating the sequence of headers
- an optio= nal request body

The request body will be read by the ser= ver only if one of the headers is a Content-Length header, and the value of= the header is exactly the number of bytes that is being sent, there is no = CRLF terminating the body.=A0 So if there is no body, the request ends with= two CRLFs, if there is a body, it just ends with [Content-Length] bytes of= raw data. There is no possibility a proper HTTP server could be confused b= y a request being terminated with two CRLFs, if the request is otherwise co= rrect. I think there must have been some confusion as to the reason of the = original problem, that was then turned into this "fix".

For reference, my code is roughly this, and as mentioned I a= m using net.http from the Go language on the other end:

(defun serve= r-command (command)
=A0 (let* ((url-request-method "POST")
=A0=A0=A0=A0=A0=A0=A0=A0 (url-request-extra-headers '(("Content-Ty= pe" . "application/x-www-form-urlencoded")))
=A0=A0=A0=A0= =A0=A0=A0=A0 (url-request-data (concat (url-hexify-string "command&quo= t;) "=3D" (url-hexify-string (json-encode command))))
=A0=A0=A0=A0=A0=A0=A0=A0 (result-buffer (url-retrieve-synchronously server-= url))
=A0=A0=A0=A0=A0=A0=A0=A0 (result
=A0=A0=A0=A0=A0=A0=A0=A0=A0 (w= ith-current-buffer result-buffer
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (goto= -char (point-min))
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (delete-region (poi= nt-min) (search-forward "\n\n"))
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (buffer-string))))
=A0=A0=A0 (kill-buf= fer result-buffer)
=A0=A0=A0 result))

Normally I get from t= his function the contents of the first, "correct" response body f= rom the server, but if I run it a few times in quick succession I additonal= ly get the string "HTTP/1.1 400 Bad Request" at the end, which is= actually the second HTTP response showing up at random in the buffer (alto= ugh it's consistently sent by the server every time, as I can see in a = sniffer).

Cheers,
Jaros=B3aw Rzesz=F3tko
--047d7bdc7c881f476f04ee25b0f4-- From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 22 16:55:23 2013 Received: (at submit) by debbugs.gnu.org; 22 Dec 2013 21:55:23 +0000 Received: from localhost ([127.0.0.1]:34936 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VuqzX-0002Oh-Bb for submit@debbugs.gnu.org; Sun, 22 Dec 2013 16:55:22 -0500 Received: from eggs.gnu.org ([208.118.235.92]:58263) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VuqzT-0002OV-6x for submit@debbugs.gnu.org; Sun, 22 Dec 2013 16:55:16 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VuqzR-0000Lb-05 for submit@debbugs.gnu.org; Sun, 22 Dec 2013 16:55:14 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM, HTML_MESSAGE,T_DKIM_INVALID autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:41732) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VuqzQ-0000LX-TY for submit@debbugs.gnu.org; Sun, 22 Dec 2013 16:55:12 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59985) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VuqzP-0003Y7-6T for bug-gnu-emacs@gnu.org; Sun, 22 Dec 2013 16:55:12 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VuqzN-0000LI-I2 for bug-gnu-emacs@gnu.org; Sun, 22 Dec 2013 16:55:11 -0500 Received: from mail-pa0-x233.google.com ([2607:f8b0:400e:c03::233]:55261) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VuqzN-0000L2-60 for bug-gnu-emacs@gnu.org; Sun, 22 Dec 2013 16:55:09 -0500 Received: by mail-pa0-f51.google.com with SMTP id fa1so4623613pad.24 for ; Sun, 22 Dec 2013 13:55:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=4oO4U5YWTEXhxy4dAIViIPaq6fKoWy3x6DotkETkPX0=; b=tQrfIBzMvBhgj3q42+ig+0YQZKt7JigIuA4VE+FOz1g84hQty+ttsLjQl1lDpDrkXA Y4zf+WV1q4v2I7uscPYXTXV6HWcdkW10aC5DGpSfb9gJYwwkRyYxdQ+3W9oNoaeEj52q AdUxutW3hdBE3hUxNER4yYdoNllZ1+zhYlo3ODzb5Af2HXPffGzvVehoUmh2An3IJyrK 5lxlocreN6zSjVjLJqBPbuPAayin68PVRiiACJ+UY0hMZMrRYwgvzY4IiRLR7jcjCaes kP1GM9362rT7yymsKT8EjW0BvojgmmGlyEexNio6teCc2IoLGjS6rcjJOsKmd5M1JRz9 WSfQ== MIME-Version: 1.0 X-Received: by 10.66.161.1 with SMTP id xo1mr436572pab.146.1387749308038; Sun, 22 Dec 2013 13:55:08 -0800 (PST) Received: by 10.66.77.230 with HTTP; Sun, 22 Dec 2013 13:55:07 -0800 (PST) In-Reply-To: References: Date: Sun, 22 Dec 2013 22:55:07 +0100 Message-ID: Subject: Re: url-http.el: Not conforming to HTTP spec From: =?ISO-8859-2?Q?Jaros=B3aw_Rzesz=F3tko?= To: bug-gnu-emacs@gnu.org Content-Type: multipart/alternative; boundary=047d7b86c2ca8b047b04ee26907d X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.0 (----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.0 (----) --047d7b86c2ca8b047b04ee26907d Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable Hi, To turn this into a concrete proposal: I suggest this part in url-http.el (starting line 356 in trunk): ;; End request "\r\n" ;; Any data url-http-data ;; If `url-http-data' is nil, avoid two CRLFs (Bug#8931). (if url-http-data "\r\n"))) Should read simply: ;; End request "\r\n" ;; Any data url-http-data)) I believe that the person who originally introduced the additional newline most likely was confused by some issue in mediawiki.el itself, a broken HTTP server, a broken PHP script, or something of this kind, and obscured the real bug instead of fixing it: http://bzr.savannah.gnu.org/lh/emacs/trunk/revision/100681 http://article.gmane.org/gmane.emacs.diffs/105629 I have confirmed that HTTPS connections work just fine after removing the new line, which is unsurprising, because this is what valid HTTP looks like. In fact, anyone can, using https://posttestserver.com/, easily check that the use case used as motivation for the original change, works just fine after removing that additional newline as I suggest here: (let ((url-request-method "POST") (url-request-data "action=3Dlogin")) (url-retrieve-synchronously "https://posttestserver.com/post.php")) Futhermore url-http-attempt-keepalives should be nil as default, or better yet should be completely removed, as true keepalive connections are anyway not currently supported on the Emacs side, are they? Cheers, Jaros=B3aw Rzesz=F3tko 2013/12/22 Jaros=B3aw Rzesz=F3tko > Hi, > > At the end of every HTTP request to be made with url-http.el and > containing a body, an unnecessary "\r\n" is appended, and additionally > those two characters are not used in the calculation of the Content-Lengt= h > header. This normally would not matter, because a carefully build server > will anyway only read "Content-Length" bytes from the body and ignore the > final CRLF, but Emacs additionally defaults to using Connection: > keep-alive, which results in the TCP traffic for what was meant to be a > single request, being interpreted as two separate HTTP requests, the firs= t > one being roughly the intended one, and the other one consisting only of > CRLF. In particular, I am using the HTTP server from net.http in Go > language. That keepalive is enabled by default is strange, especially giv= en > how the variable that controls this is described: > > (defvar url-http-attempt-keepalives t > "Whether to use a single TCP connection multiple times in HTTP. > This is only useful when debugging the HTTP subsystem. Setting to > nil will explicitly close the connection to the server after every > request.") > > Those issues have been somewhat discussed here, but it seems the people > discussing unfortunately don't understand HTTP: > > > https://groups.google.com/forum/#!msg/gnu.emacs.bug/SF4P7gVI6IQ/SExtWzutK= I4J > > Please just compare this discussion to > http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html > > If you don't go into any fancy things like chunked encoding etc., an HTTP > request is a: > > - sequence of headers, each header followed with a newline > - a newline terminating the sequence of headers > - an optional request body > > The request body will be read by the server only if one of the headers is > a Content-Length header, and the value of the header is exactly the numbe= r > of bytes that is being sent, there is no CRLF terminating the body. So i= f > there is no body, the request ends with two CRLFs, if there is a body, it > just ends with [Content-Length] bytes of raw data. There is no possibilit= y > a proper HTTP server could be confused by a request being terminated with > two CRLFs, if the request is otherwise correct. I think there must have > been some confusion as to the reason of the original problem, that was th= en > turned into this "fix". > > For reference, my code is roughly this, and as mentioned I am using > net.http from the Go language on the other end: > > (defun server-command (command) > (let* ((url-request-method "POST") > (url-request-extra-headers '(("Content-Type" . > "application/x-www-form-urlencoded"))) > (url-request-data (concat (url-hexify-string "command") "=3D" > (url-hexify-string (json-encode command)))) > (result-buffer (url-retrieve-synchronously server-url)) > (result > (with-current-buffer result-buffer > (goto-char (point-min)) > (delete-region (point-min) (search-forward "\n\n")) > (buffer-string)))) > (kill-buffer result-buffer) > result)) > > Normally I get from this function the contents of the first, "correct" > response body from the server, but if I run it a few times in quick > succession I additonally get the string "HTTP/1.1 400 Bad Request" at the > end, which is actually the second HTTP response showing up at random in t= he > buffer (altough it's consistently sent by the server every time, as I can > see in a sniffer). > > Cheers, > Jaros=B3aw Rzesz=F3tko > --047d7b86c2ca8b047b04ee26907d Content-Type: text/html; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable
Hi,

To turn this into a concret= e proposal: I suggest this part in url-http.el (starting line 356 in trunk)= :

;; End request
"\r\n"
;; Any data
url-http-data=
;; If `url-http-data' is nil, avoid two CRLFs (Bug#8931).
(if url-ht= tp-data "\r\n")))

Should read simply:

;; End = request
"\r\n"
;; Any data
url-http-data))

I believe that the person who originally introduced the additional newline = most likely was confused by some issue in mediawiki.el itself, a broken HTT= P server, a broken PHP script, or something of this kind, and obscured the = real bug instead of fixing it:

= http://bzr.savannah.gnu.org/lh/emacs/trunk/revision/100681
http://article.gmane= .org/gmane.emacs.diffs/105629

I have confirmed that HTTPS connections work just fine= after removing the new line, which is unsurprising, because this is what v= alid HTTP looks like. In fact, anyone can, using https://posttestserver.com/, easily check that the use c= ase used as motivation for the original change, works just fine after remov= ing that additional newline as I suggest here:

(let ((url-request-method "POST")
=A0=A0=A0=A0=A0 (url-req= uest-data "action=3Dlogin"))
=A0 (url-retrieve-synchronously &= quot;https://posttestserver= .com/post.php"))

Futhermore url-http-attempt-keepalives should be nil as default, or bet= ter yet should be completely removed, as true keepalive connections are any= way not currently supported on the Emacs side, are they?

Cheer= s,
Jaros=B3aw Rzesz=F3tko


2013/12/22 Jaros=B3aw Rzesz=F3tko <= sztywny@gmail.com>
Hi,

At the= end of every HTTP request to be made with url-http.el and containing a bod= y, an unnecessary "\r\n" is appended, and additionally those two = characters are not used in the calculation of the Content-Length header. Th= is normally would not matter, because a carefully build server will anyway = only read "Content-Length" bytes from the body and ignore the fin= al CRLF, but Emacs additionally defaults to using Connection: keep-alive, w= hich results in the TCP traffic for what was meant to be a single request, = being interpreted as two separate HTTP requests, the first one being roughl= y the intended one, and the other one consisting only of CRLF. In particula= r, I am using the HTTP server from net.http in Go language. That keepalive = is enabled by default is strange, especially given how the variable that co= ntrols this is described:

(defvar url-http-attempt-keepalives t
=A0 "Whether to use = a single TCP connection multiple times in HTTP.
This is only useful when= debugging the HTTP subsystem.=A0 Setting to
nil will explicitly close t= he connection to the server after every
request.")

Those issues have been somewhat discussed here= , but it seems the people discussing unfortunately don't understand HTT= P:

https://groups.google.com/forum/#= !msg/gnu.emacs.bug/SF4P7gVI6IQ/SExtWzutKI4J

Please just compare this discussion to http://www.w= 3.org/Protocols/rfc2616/rfc2616-sec4.html

If you don't go i= nto any fancy things like chunked encoding etc., an HTTP request is a:

- sequence of headers, each header followed with a newline
- a newline terminating the sequence of headers
- an optio= nal request body

The request body will be read by the ser= ver only if one of the headers is a Content-Length header, and the value of= the header is exactly the number of bytes that is being sent, there is no = CRLF terminating the body.=A0 So if there is no body, the request ends with= two CRLFs, if there is a body, it just ends with [Content-Length] bytes of= raw data. There is no possibility a proper HTTP server could be confused b= y a request being terminated with two CRLFs, if the request is otherwise co= rrect. I think there must have been some confusion as to the reason of the = original problem, that was then turned into this "fix".

For reference, my code is roughly this, and as mentioned I a= m using net.http from the Go language on the other end:

(defun serve= r-command (command)
=A0 (let* ((url-request-method "POST")
=A0=A0=A0=A0=A0=A0=A0=A0 (url-request-extra-headers '(("Content-Ty= pe" . "application/x-www-form-urlencoded")))
=A0=A0=A0=A0= =A0=A0=A0=A0 (url-request-data (concat (url-hexify-string "command&quo= t;) "=3D" (url-hexify-string (json-encode command))))
=A0=A0=A0=A0=A0=A0=A0=A0 (result-buffer (url-retrieve-synchronously server-= url))
=A0=A0=A0=A0=A0=A0=A0=A0 (result
=A0=A0=A0=A0=A0=A0=A0=A0=A0 (w= ith-current-buffer result-buffer
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (goto= -char (point-min))
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (delete-region (poi= nt-min) (search-forward "\n\n"))
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (buffer-string))))
=A0=A0=A0 (kill-buf= fer result-buffer)
=A0=A0=A0 result))

Normally I get from t= his function the contents of the first, "correct" response body f= rom the server, but if I run it a few times in quick succession I additonal= ly get the string "HTTP/1.1 400 Bad Request" at the end, which is= actually the second HTTP response showing up at random in the buffer (alto= ugh it's consistently sent by the server every time, as I can see in a = sniffer).

Cheers,
Jaros=B3aw Rzesz=F3tko

--047d7b86c2ca8b047b04ee26907d-- From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 22 17:32:22 2013 Received: (at 16220) by debbugs.gnu.org; 22 Dec 2013 22:32:22 +0000 Received: from localhost ([127.0.0.1]:34963 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VurZO-0003Sp-EA for submit@debbugs.gnu.org; Sun, 22 Dec 2013 17:32:22 -0500 Received: from mail-qc0-f175.google.com ([209.85.216.175]:49936) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VurZM-0003Sf-8t for 16220@debbugs.gnu.org; Sun, 22 Dec 2013 17:32:20 -0500 Received: by mail-qc0-f175.google.com with SMTP id e9so4183785qcy.6 for <16220@debbugs.gnu.org>; Sun, 22 Dec 2013 14:32:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lifelogs.com; s=google; h=from:to:cc:subject:organization:references:mail-copies-to :gmane-reply-to-list:date:in-reply-to:message-id:user-agent :mime-version:content-type:content-transfer-encoding; bh=BxC4VkmemMXebBb5LSvC1E1GOvHLNs4N4a8oMYr7x3E=; b=aMYN+CtRR66LwX2xrJTUk7fEbq7/slH5Yia7qNKgnAHf8K3kLB1uaOw3qm5aWYeInm AT1WrAX3hDAoa6NYU2StasHbgv7Btt5PEJDyuF177kd/9wgSZ+USYyE08DzMd6e1gFuH uBlgK+063+gf3ffUAJqp3pV17QbpvUE3cXnAE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:organization:references :mail-copies-to:gmane-reply-to-list:date:in-reply-to:message-id :user-agent:mime-version:content-type:content-transfer-encoding; bh=BxC4VkmemMXebBb5LSvC1E1GOvHLNs4N4a8oMYr7x3E=; b=AQiBZAeugsXQSe1aSaEgM5cqGBCJRtF6Kc9RVlncHNimmxyRGzzLdJs03HCz9fV16j HgMIBrdegR2GeGb2yvi0s9ek9EoSw7IN0R5fCC+th/L7Y1JFIiF+8hSXMoI+y/wVrs4Z BiFhIpa0tTsMlcnq7krobsv7ZVikiR7ytmYvQv6AEtz6Kcc7dpNTj0dYBzf5MFWfdNFs iBz3EqAhtxZ4oxZF6waNkiJC/023yiv3kLXoSH4ypjP7hYbeR5u63YjDfa5zBNp4rl+U wSx47VdbcKfsnIaGBXWjr1gYBCCgj4tyL5bhlsyAtbpsdMb4Wmwe38b80rmbYb41bvte R/aQ== X-Gm-Message-State: ALoCoQmPMSw2Ywhu1vwxqg7T3oLtru9szcfRqn/hhYgl+sdoyUzcoVWyIri+MKjkb9I6WC12Ylql X-Received: by 10.224.97.7 with SMTP id j7mr37053720qan.81.1387751539786; Sun, 22 Dec 2013 14:32:19 -0800 (PST) Received: from flea.lifelogs.com (c-98-229-61-72.hsd1.ma.comcast.net. [98.229.61.72]) by mx.google.com with ESMTPSA id ki4sm29634978qeb.0.2013.12.22.14.32.18 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 22 Dec 2013 14:32:19 -0800 (PST) From: Ted Zlatanov To: =?utf-8?Q?Jaros=C5=82aw_Rzesz=C3=B3tko?= Subject: Re: bug#16220: url-http.el: Not conforming to HTTP spec Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos References: X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6; d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" Mail-Copies-To: never Gmane-Reply-To-List: yes Date: Sun, 22 Dec 2013 17:33:41 -0500 In-Reply-To: (=?utf-8?Q?=22Jaros=C5=82aw_Rzesz=C3=B3tko=22's?= message of "Sun, 22 Dec 2013 22:55:07 +0100") Message-ID: <87wqiwbjne.fsf@flea.lifelogs.com> User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 16220 Cc: 16220@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On Sun, 22 Dec 2013 22:55:07 +0100 Jaros=C5=82aw Rzesz=C3=B3tko wrote:=20 JR> To turn this into a concrete proposal: I suggest this part in url-http.= el JR> (starting line 356 in trunk): JR> ;; End request JR> "\r\n" JR> ;; Any data JR> url-http-data JR> ;; If `url-http-data' is nil, avoid two CRLFs (Bug#8931). JR> (if url-http-data "\r\n"))) JR> Should read simply: JR> ;; End request JR> "\r\n" JR> ;; Any data JR> url-http-data)) ... JR> Futhermore url-http-attempt-keepalives should be nil as default, or bet= ter JR> yet should be completely removed, as true keepalive connections are any= way JR> not currently supported on the Emacs side, are they? Jaros=C5=82aw, can you please check if your fix corrects https://github.com/milkypostman/melpa/issues/1193 which seems somewhat rela= ted? I don't know much about this area but your fix could help this annoying issue as well, if it's valid. Ted From debbugs-submit-bounces@debbugs.gnu.org Mon Dec 23 01:52:02 2013 Received: (at 16220) by debbugs.gnu.org; 23 Dec 2013 06:52:02 +0000 Received: from localhost ([127.0.0.1]:35247 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VuzMv-00022c-LN for submit@debbugs.gnu.org; Mon, 23 Dec 2013 01:52:02 -0500 Received: from mail-pd0-f182.google.com ([209.85.192.182]:60499) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VuzMs-00022Q-Tp for 16220@debbugs.gnu.org; Mon, 23 Dec 2013 01:51:59 -0500 Received: by mail-pd0-f182.google.com with SMTP id v10so4830212pde.13 for <16220@debbugs.gnu.org>; Sun, 22 Dec 2013 22:51:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=VHnVwjjQx89TXJGxTzNXlt+4DgUxL3+4etzPdG7Q/gQ=; b=F2TKmvn8noL6PoVk2hxZk/I6fnU8WPHYClahhcjCmuBwwBpMNDyoFDG+zcq2v42tuI jANhaR9R9shbxL4fip4T6qS082A4ySoVygYbvWKPvJZOCqPENJyZL9Rcpqcsgk5DfcvT 8LUtJSQnwsfACvDKc6K7CQDbNib8YK5j94TxETu/R6f/OjaCkIyAYy4AjCKb51g3Nxnm 0nlmaxjP+twKZz4u4bOrIY5uryzZM1CqzQ9uuZ/a4DDDbxbH0SDLPSaIk3gskjq70exb mmtNIuxDPUR3KdEbmMrGc6Vjd0V+3DtbvnfAmy4oHdF1hjec8P5Lb84O7zEbMM+MUOIL FDtA== MIME-Version: 1.0 X-Received: by 10.69.19.225 with SMTP id gx1mr24267305pbd.62.1387781517964; Sun, 22 Dec 2013 22:51:57 -0800 (PST) Received: by 10.66.77.230 with HTTP; Sun, 22 Dec 2013 22:51:57 -0800 (PST) In-Reply-To: <87wqiwbjne.fsf@flea.lifelogs.com> References: <87wqiwbjne.fsf@flea.lifelogs.com> Date: Mon, 23 Dec 2013 07:51:57 +0100 Message-ID: Subject: Re: bug#16220: url-http.el: Not conforming to HTTP spec From: =?ISO-8859-2?Q?Jaros=B3aw_Rzesz=F3tko?= To: Ted Zlatanov Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 16220 Cc: 16220@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) Hi, No, this does not seem directly related - I can't reproduce the GH error neither with or without my fix, and from the discussion at the end of the GH issue, it seems it has been fixed by the elpa guys by adjusting server configuration. As for the validity of the fix, I found the passage in the spec the addresses this issue directly (once again from http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html): "Certain buggy HTTP/1.0 client implementations generate extra CRLF's after a POST request. To restate what is explicitly forbidden by the BNF, an HTTP/1.1 client MUST NOT preface or follow a request with an extra CRLF." The BNF this refers to is this: generic-message =3D start-line *(message-header CRLF) CRLF [ message-body ] start-line =3D Request-Line | Status-Line And finally: "When a Content-Length is given in a message where a message-body is allowed, its field value MUST exactly match the number of OCTETs in the message-body. HTTP/1.1 user agents MUST notify the user when an invalid length is received and detected." I hope this is enough of a proof that the extra newline is a bug. Cheers, Jaros=B3aw Rzesz=F3tko 2013/12/22 Ted Zlatanov : > On Sun, 22 Dec 2013 22:55:07 +0100 Jaros=B3aw Rzesz=F3tko wrote: > > JR> To turn this into a concrete proposal: I suggest this part in url-htt= p.el > JR> (starting line 356 in trunk): > > JR> ;; End request > JR> "\r\n" > JR> ;; Any data > JR> url-http-data > JR> ;; If `url-http-data' is nil, avoid two CRLFs (Bug#8931). > JR> (if url-http-data "\r\n"))) > > JR> Should read simply: > > JR> ;; End request > JR> "\r\n" > JR> ;; Any data > JR> url-http-data)) > ... > JR> Futhermore url-http-attempt-keepalives should be nil as default, or b= etter > JR> yet should be completely removed, as true keepalive connections are a= nyway > JR> not currently supported on the Emacs side, are they? > > Jaros=B3aw, > > can you please check if your fix corrects > https://github.com/milkypostman/melpa/issues/1193 which seems somewhat re= lated? > > I don't know much about this area but your fix could help this annoying > issue as well, if it's valid. > > Ted From debbugs-submit-bounces@debbugs.gnu.org Mon Dec 23 08:07:23 2013 Received: (at 16220) by debbugs.gnu.org; 23 Dec 2013 13:07:24 +0000 Received: from localhost ([127.0.0.1]:35466 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Vv5EB-0007Ck-Gb for submit@debbugs.gnu.org; Mon, 23 Dec 2013 08:07:23 -0500 Received: from mail-qe0-f43.google.com ([209.85.128.43]:40792) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Vv5E9-0007Cc-FS for 16220@debbugs.gnu.org; Mon, 23 Dec 2013 08:07:22 -0500 Received: by mail-qe0-f43.google.com with SMTP id jy17so5090314qeb.30 for <16220@debbugs.gnu.org>; Mon, 23 Dec 2013 05:07:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lifelogs.com; s=google; h=from:to:cc:subject:organization:references:mail-copies-to :gmane-reply-to-list:date:in-reply-to:message-id:user-agent :mime-version:content-type:content-transfer-encoding; bh=kF3LOqUGu4cDR6hkC2m3Pvg8sGtyHRtRr68rP3HRRWk=; b=j4bOmGu3LDiRwBYOYQhNtGtVDjm6Xf5k1fcXd3RMABRmFdL/qGYREhqnIsjTq+4CQk 8iRkuOli29jeT+qWaIg2x0Ksx+jpy49gIsO+ldLhZFh0HbA1dg7KR3v5R6Ly3hxOWVm4 QO5szSymMthOhPA9cd/JBeAFUyoSGw7SObXs8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:organization:references :mail-copies-to:gmane-reply-to-list:date:in-reply-to:message-id :user-agent:mime-version:content-type:content-transfer-encoding; bh=kF3LOqUGu4cDR6hkC2m3Pvg8sGtyHRtRr68rP3HRRWk=; b=nHZs8+RLNcpuM35PPnp6VZWXf1vnzZERFcd+D2av13NDin/gUsapjvjqgCOOuGTmif SOEy7PgLsjoLhqJgtP8xMR07PlfLlM4RJ5Xw4bMdERbhkopilxqgVeMUtNyQ0zgs6pW/ 4o4A7JX9hIuKEUEUqfW+m/EySrijmpEj6u191hUelf1adGBK4FZ6ZFbKcmcZac+zQumQ 6oD5D6qJJGg7L5dsX7JqhL9AfeICtu24bd0LbHEuowMRhwnoDoblkjxTQMmwUeF9IZki h998TCnsovUn6fq5p8WC5b1b08amb8FCHheNFAF72nfmhk9BXnxTeKuVwWFxAthHaH2c bEQw== X-Gm-Message-State: ALoCoQkMZn9yQ4P3np+35VHKUiLIkc0afms92VWOpMZHV1Z00Xa0aFNXIjZfxKpduNReePhJUlGs X-Received: by 10.224.11.68 with SMTP id s4mr42135985qas.88.1387804040505; Mon, 23 Dec 2013 05:07:20 -0800 (PST) Received: from flea.lifelogs.com (c-98-229-61-72.hsd1.ma.comcast.net. [98.229.61.72]) by mx.google.com with ESMTPSA id ni10sm21974861qeb.23.2013.12.23.05.07.19 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Dec 2013 05:07:19 -0800 (PST) From: Ted Zlatanov To: =?utf-8?Q?Jaros=C5=82aw_Rzesz=C3=B3tko?= Subject: Re: bug#16220: url-http.el: Not conforming to HTTP spec Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos References: <87wqiwbjne.fsf@flea.lifelogs.com> X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6; d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" Mail-Copies-To: never Gmane-Reply-To-List: yes Date: Mon, 23 Dec 2013 08:08:42 -0500 In-Reply-To: (=?utf-8?Q?=22Jaros=C5=82aw_Rzesz=C3=B3tko=22's?= message of "Mon, 23 Dec 2013 07:51:57 +0100") Message-ID: <87ha9zaf51.fsf@flea.lifelogs.com> User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 16220 Cc: 16220@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On Mon, 23 Dec 2013 07:51:57 +0100 Jaros=C5=82aw Rzesz=C3=B3tko wrote:=20 JR> I hope this is enough of a proof that the extra newline is a bug. I was already convinced :) JR> 2013/12/22 Ted Zlatanov : >> On Sun, 22 Dec 2013 22:55:07 +0100 Jaros=C5=82aw Rzesz=C3=B3tko wrote: >>=20 JR> To turn this into a concrete proposal: I suggest this part in url-http.= el JR> (starting line 356 in trunk): >>=20 JR> ;; End request JR> "\r\n" JR> ;; Any data JR> url-http-data JR> ;; If `url-http-data' is nil, avoid two CRLFs (Bug#8931). JR> (if url-http-data "\r\n"))) >>=20 JR> Should read simply: >>=20 JR> ;; End request JR> "\r\n" JR> ;; Any data JR> url-http-data)) >> ... I am OK with this fix, if anyone else wants to look it over and commit. JR> Futhermore url-http-attempt-keepalives should be nil as default, or bet= ter JR> yet should be completely removed, as true keepalive connections are any= way JR> not currently supported on the Emacs side, are they? Not AFAIK. Ted From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 24 02:56:24 2013 Received: (at 16220) by debbugs.gnu.org; 24 Dec 2013 07:56:24 +0000 Received: from localhost ([127.0.0.1]:37568 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VvMql-00028T-5z for submit@debbugs.gnu.org; Tue, 24 Dec 2013 02:56:23 -0500 Received: from hermes.netfonds.no ([80.91.224.195]:55020) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VvMqh-00028J-SA for 16220@debbugs.gnu.org; Tue, 24 Dec 2013 02:56:20 -0500 Received: from 77.18.245.69.tmi.telenormobil.no ([77.18.245.69] helo=building.gnus.org) by hermes.netfonds.no with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1VvMqT-0007q2-Jz; Tue, 24 Dec 2013 08:56:05 +0100 From: Lars Ingebrigtsen To: =?utf-8?Q?Jaros=C5=82aw_Rzesz=C3=B3tko?= Subject: Re: bug#16220: url-http.el: Not conforming to HTTP spec References: Date: Tue, 24 Dec 2013 08:50:11 +0100 In-Reply-To: (=?utf-8?Q?=22Jaros=C5=82aw_Rzesz=C3=B3tko=22's?= message of "Sun, 22 Dec 2013 22:55:07 +0100") Message-ID: <87sitiy9fw.fsf@building.gnus.org> User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-MailScanner-ID: 1VvMqT-0007q2-Jz X-Netfonds-MailScanner: Found to be clean X-Netfonds-MailScanner-From: larsi@gnus.org MailScanner-NULL-Check: 1388476566.49806@paVH6ksFsgT6HDPBdSADdw X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 16220 Cc: 16220@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) Jaros=C5=82aw Rzesz=C3=B3tko writes: > I believe that the person who originally introduced the additional > newline most likely was confused by some issue in mediawiki.el itself, > a broken HTTP server, a broken PHP script, or something of this kind, > and obscured the real bug instead of fixing it: Well, that's possible. If there's a significant number of these broken HTTP servers, then including the workaround is the correct thing to do. I don't know whether that's the case, though. --=20 (domestic pets only, the antidote for overdose, milk.) bloggy blog http://lars.ingebrigtsen.no/ From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 24 03:28:20 2013 Received: (at 16220) by debbugs.gnu.org; 24 Dec 2013 08:28:20 +0000 Received: from localhost ([127.0.0.1]:37635 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VvNLb-0004Ar-Tl for submit@debbugs.gnu.org; Tue, 24 Dec 2013 03:28:19 -0500 Received: from mail-pb0-f46.google.com ([209.85.160.46]:42034) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VvNLV-0004AZ-6D for 16220@debbugs.gnu.org; Tue, 24 Dec 2013 03:28:13 -0500 Received: by mail-pb0-f46.google.com with SMTP id md12so6204876pbc.19 for <16220@debbugs.gnu.org>; Tue, 24 Dec 2013 00:28:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=mNWozqWL21/jHwJZPRW73gem8rSRL/AHN2ij9gxyt8s=; b=fljP4bQU1ucS9/4l1aD0bwnZgl9F9pJb4sntVNTlhF5KteiRI7EFIrbdeW7nn+WA0P zs95+pVTMiLnK/HoP6VftsTZ1HpbrrgiVR9WHPTrHIW7GFjiNZRd24L4SMYwV9tGgkJp lBOa6en1eynRySum/jnc2Ff09DJyXOXYaFdZZIuF6CRx2/mUnxwQlEPQ+/CvvKeHH3u9 B6iE998PeZwQhGNIclPjfgdCcQRScGbNIOukYfCnvNJb31eZjMUGP09MI1ePvgUR1cpR ZdQGeZvs/3YSpiM3Az4g2NBCn6Ds4lSIcg6Az06EDlYxghTaxSfqrW2MOWyowMy+6PXk yjtw== MIME-Version: 1.0 X-Received: by 10.66.161.1 with SMTP id xo1mr8410282pab.146.1387873688148; Tue, 24 Dec 2013 00:28:08 -0800 (PST) Received: by 10.66.77.230 with HTTP; Tue, 24 Dec 2013 00:28:08 -0800 (PST) In-Reply-To: <87sitiy9fw.fsf@building.gnus.org> References: <87sitiy9fw.fsf@building.gnus.org> Date: Tue, 24 Dec 2013 09:28:08 +0100 Message-ID: Subject: Re: bug#16220: url-http.el: Not conforming to HTTP spec From: =?ISO-8859-2?Q?Jaros=B3aw_Rzesz=F3tko?= To: Lars Ingebrigtsen Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 16220 Cc: 16220@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Hi, There are no "real" HTTP servers that require this, as evidenced by the fact that none of the popular HTTP clients does this, just have a look at curl source code or the http library of your favourite programming language. Frankly, this is broken so obviously I feel stupid further discussing it. Cheers, Jaros=B3aw Rzesz=F3tko 2013/12/24 Lars Ingebrigtsen : > Jaros=B3aw Rzesz=F3tko writes: > >> I believe that the person who originally introduced the additional >> newline most likely was confused by some issue in mediawiki.el itself, >> a broken HTTP server, a broken PHP script, or something of this kind, >> and obscured the real bug instead of fixing it: > > Well, that's possible. If there's a significant number of these broken > HTTP servers, then including the workaround is the correct thing to do. > > I don't know whether that's the case, though. > > -- > (domestic pets only, the antidote for overdose, milk.) > bloggy blog http://lars.ingebrigtsen.no/ From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 24 09:43:24 2013 Received: (at 16220) by debbugs.gnu.org; 24 Dec 2013 14:43:24 +0000 Received: from localhost ([127.0.0.1]:38314 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VvTCd-0001hO-Pp for submit@debbugs.gnu.org; Tue, 24 Dec 2013 09:43:24 -0500 Received: from pruche.dit.umontreal.ca ([132.204.246.22]:37045) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VvTCb-0001hF-43 for 16220@debbugs.gnu.org; Tue, 24 Dec 2013 09:43:21 -0500 Received: from fmsmemgm.homelinux.net (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id rBOEhIqj010913; Tue, 24 Dec 2013 09:43:19 -0500 Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id D9056AE086; Tue, 24 Dec 2013 09:43:17 -0500 (EST) From: Stefan Monnier To: =?utf-8?Q?Jaros=C5=82aw_Rzesz=C3=B3tko?= Subject: Re: bug#16220: url-http.el: Not conforming to HTTP spec Message-ID: References: Date: Tue, 24 Dec 2013 09:43:17 -0500 In-Reply-To: (=?utf-8?Q?=22Jaros=C5=82aw_Rzesz=C3=B3tko=22's?= message of "Sun, 22 Dec 2013 21:52:22 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0.2 X-NAI-Spam-Rules: 2 Rules triggered GEN_SPAM_FEATRE=0.2, RV4802=0 X-NAI-Spam-Version: 2.3.0.9362 : core <4802> : inlines <357> : streams <1096294> : uri <1633813> X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 16220 Cc: 16220@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.9 (-) > At the end of every HTTP request to be made with url-http.el and containing > a body, an unnecessary "\r\n" is appended, and additionally those two > characters are not used in the calculation of the Content-Length header. Looks like an old workaround. Could someone get rid of this? Stefan From debbugs-submit-bounces@debbugs.gnu.org Tue Dec 24 11:32:00 2013 Received: (at 16220) by debbugs.gnu.org; 24 Dec 2013 16:32:00 +0000 Received: from localhost ([127.0.0.1]:39288 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VvUtk-0005E3-38 for submit@debbugs.gnu.org; Tue, 24 Dec 2013 11:32:00 -0500 Received: from mail-pd0-f178.google.com ([209.85.192.178]:49176) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VvUti-0005Du-3Z for 16220@debbugs.gnu.org; Tue, 24 Dec 2013 11:31:58 -0500 Received: by mail-pd0-f178.google.com with SMTP id y10so6471663pdj.37 for <16220@debbugs.gnu.org>; Tue, 24 Dec 2013 08:31:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=/DHCHT+PpSLq079xr7eSEfW4t70A2eGfAnL2txcdJJ4=; b=a2gcjp2eHPxngS875tH0zU9Y2ZXJvha/govITk3XcQRX04alehj6WpNRPl2BWc1uqk bPQ44/scqPTzk/hOUQAYj6jIxED2p8JeqB27uQ3FmyHB2BGHBS9JVxoYJTh5Z5KeyVYD 6tU8ym6d56d2a7grh9Zf6QhrpYMtg2OK+VfF9bHP0o0B760+G+Tvg4PIKw1fiJ3Bo9jv nQpw3K+vGSOT1EFWHOSx0VpN6QlFQ457iYNsgCOwRK/GbeHYtTmJbz0NtUQpTDmW03eC dCDh4mmoiNrAOIe2y2TqajE+N0PzZVyXdanIQhOeVzUf2bKiRmPBmH0MGeaxLHcH3+Wh DqWg== MIME-Version: 1.0 X-Received: by 10.67.21.130 with SMTP id hk2mr33205100pad.76.1387902717148; Tue, 24 Dec 2013 08:31:57 -0800 (PST) Received: by 10.66.77.230 with HTTP; Tue, 24 Dec 2013 08:31:57 -0800 (PST) In-Reply-To: References: Date: Tue, 24 Dec 2013 17:31:57 +0100 Message-ID: Subject: Re: bug#16220: url-http.el: Not conforming to HTTP spec From: =?ISO-8859-2?Q?Jaros=B3aw_Rzesz=F3tko?= To: Stefan Monnier Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 16220 Cc: 16220@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) Hi, There are more issues besides just the extra "\r\n", the url-http.el library is super confusing. I read the documentation for url-retrieve, which makes doing a HTTP request look really straightforward, and then I spent several hours finding out what the hell happens. For example, the documentation for url-retrieve says: "The variables `url-request-data', `url-request-method' and `url-request-extra-headers' can be dynamically bound around the request; dynamic binding of other variables doesn't necessarily take effect." The problem is that url-http.el sets a lot of headers by default that can not be overwritten in any other way then dynamically overshadowing some variables. For example, all connections are keep-alive by default, which is confusing in itself already, futhermore you can't just pass "Connection" . "close' in url-request-extra-headers, because url-http.el joins the default and "extra" headers instead of merging the "extra" ones and having them overwrite the default ones. So try do something like this: (let ((url-request-method "GET") (url-request-extra-headers '(("Connection" . "close")))) (url-retrieve-synchronously "http://www.google.com/")) And what is sent is this: GET / HTTP/1.1 Connection: keep-alive ... Connection: close Which again isn't valid HTTP and the behaviour of the HTTP server in this case is undefined and implementation specific. The only way to workaround this is doing this: (let ((url-http-attempt-keepalives nil) (url-request-method "GET") (url-request-extra-headers '(("Connection" . "close")))) (url-retrieve-synchronously "http://www.google.com/")) Which is only clear by reading url-http.el where again it is described in a very confusing way: (defvar url-http-attempt-keepalives t "Whether to use a single TCP connection multiple times in HTTP. This is only useful when debugging the HTTP subsystem. Setting to nil will explicitly close the connection to the server after every request.") This is all the more irritating so many of the headers are set by default using the variables url-vars.el. Why those things are at all variables is a mystery to me. Then there are messages that appear in the minibuffer and there is no way to disable them. In the end it is much easier to do HTTP requests manually using make-network-process then it is with the url library, it really isn't a good general purpose HTTP component, there are too many completely opaque things happening behind the scenes, like the hashmap of persistent tcp connections that is maintained behind the scenes. Didn't anyone else run into problems with it? Cheers, Jaros=B3aw Rzesz=F3tko 2013/12/24 Stefan Monnier : >> At the end of every HTTP request to be made with url-http.el and contain= ing >> a body, an unnecessary "\r\n" is appended, and additionally those two >> characters are not used in the calculation of the Content-Length header. > > Looks like an old workaround. Could someone get rid of this? > > > Stefan From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 01 21:21:09 2014 Received: (at 16220) by debbugs.gnu.org; 2 Jan 2014 02:21:09 +0000 Received: from localhost ([127.0.0.1]:56906 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VyXuG-0008BK-Pu for submit@debbugs.gnu.org; Wed, 01 Jan 2014 21:21:09 -0500 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:46769) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VyXuD-0008BB-SQ for 16220@debbugs.gnu.org; Wed, 01 Jan 2014 21:21:06 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABK/CFHO+J7K/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLBy0SFBgNJIgeBsEtkQoDiGGcGYFegxU X-IPAS-Result: Av4EABK/CFHO+J7K/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLBy0SFBgNJIgeBsEtkQoDiGGcGYFegxU X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="43737613" Received: from 206-248-158-202.dsl.teksavvy.com (HELO pastel.home) ([206.248.158.202]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 01 Jan 2014 21:21:05 -0500 Received: by pastel.home (Postfix, from userid 20848) id D154A60051; Wed, 1 Jan 2014 21:21:04 -0500 (EST) From: Stefan Monnier To: =?utf-8?Q?Jaros=C5=82aw_Rzesz=C3=B3tko?= Subject: Re: bug#16220: url-http.el: Not conforming to HTTP spec Message-ID: References: Date: Wed, 01 Jan 2014 21:21:04 -0500 In-Reply-To: (=?utf-8?Q?=22Jaros=C5=82aw_Rzesz=C3=B3tko=22's?= message of "Tue, 24 Dec 2013 17:31:57 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 16220 Cc: 16220@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) > The problem is that url-http.el sets a lot of headers by default that > can not be overwritten in any other way then dynamically overshadowing > some variables. Indeed, this is ugly. Improvements welcome. > For example, all connections are keep-alive by > default, which is confusing in itself already, Not sure why it should be a problem. > (let ((url-request-method "GET") > (url-request-extra-headers '(("Connection" . "close")))) > (url-retrieve-synchronously "http://www.google.com/")) > And what is sent is this: > GET / HTTP/1.1 > Connection: keep-alive > ... > Connection: close > Which again isn't valid HTTP and the behaviour of the HTTP server in > this case is undefined and implementation specific. The only way to > workaround this is doing this: > (let ((url-http-attempt-keepalives nil) > (url-request-method "GET") > (url-request-extra-headers '(("Connection" . "close")))) > (url-retrieve-synchronously "http://www.google.com/")) Yuck! We can probably fix this fairly easily by letting url-request-extra-headers override (rather than just add to) other headers. > This is all the more irritating so many of the headers are set by > default using the variables url-vars.el. Why those things are at all > variables is a mystery to me. Probably partly historical evolution (there was no place to add new "parameters", so adding dynamic vars was an easy way to add more control without breaking existing code). > In the end it is much easier to do HTTP requests manually using > make-network-process then it is with the url library, I think that's misleading: the URL library is supposed to deal with things like proxies and redirections, which "manual requests via make-network-process" probably won't handle. > Didn't anyone else run into problems with it? Apparently not yet. But I agree that the API might deserve a redesign (IIRC another problem is in the way headers in the answer are returned to the caller, which does not work consistently across different kinds of URLs (ftp, http, file, imap, ...)). Stefan From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 03 13:06:28 2014 Received: (at 16220) by debbugs.gnu.org; 3 Jan 2014 18:06:28 +0000 Received: from localhost ([127.0.0.1]:60294 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Vz98c-00052g-UF for submit@debbugs.gnu.org; Fri, 03 Jan 2014 13:06:28 -0500 Received: from mail-pd0-f179.google.com ([209.85.192.179]:35972) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Vz98a-00052W-2i for 16220@debbugs.gnu.org; Fri, 03 Jan 2014 13:06:25 -0500 Received: by mail-pd0-f179.google.com with SMTP id r10so15677207pdi.38 for <16220@debbugs.gnu.org>; Fri, 03 Jan 2014 10:06:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QyDymF1PCjCFPOKmbd6wzoyg9XGAzosbpYnL08eJ1Ds=; b=ILsFFHQSrEGRPObytO26xKjAjH6kPcWCuEZhYTXyAHCSDJNygGt6aaTLe31TkokdsD ZrsKNNLZatrgyMy+4zgCNSr+JH+Ha3cWIrEGpJ33P0TcN7FI/ytxoDGAKVDZohqcxDy0 Njw4F1n5q5iCsnA7VcHVxi6rf1U1ULThS4JBGlrezEfUis7oE42oC+gbCB/ciWJiTtiG yLQ1srShfXOk4qTJQOPI2yL3hdrTnPwU4UHJ0tX3y8r2VdEFU7rCKhlcMQnVOR+Hwt3a Fw16FbLPKjFocK5JrIkdvgSiSfjbOVmDj1I9T83peqJr7ScrO0h9jLidKrpzNfaFIDMP i5Cw== MIME-Version: 1.0 X-Received: by 10.69.19.225 with SMTP id gx1mr97380557pbd.62.1388772383104; Fri, 03 Jan 2014 10:06:23 -0800 (PST) Received: by 10.66.101.201 with HTTP; Fri, 3 Jan 2014 10:06:22 -0800 (PST) In-Reply-To: References: Date: Fri, 3 Jan 2014 19:06:22 +0100 Message-ID: Subject: Re: bug#16220: url-http.el: Not conforming to HTTP spec From: =?ISO-8859-2?Q?Jaros=B3aw_Rzesz=F3tko?= To: Stefan Monnier Content-Type: multipart/mixed; boundary=001a113675249281ec04ef14c493 X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 16220 Cc: 16220@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) --001a113675249281ec04ef14c493 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable I attach a patch that removes the extra "\r\n", adds a function to merge two alists, and uses it to merge the extra-headers on top of the default-headers. I added a few basic tests, too. Cheers, Jaros=B3aw Rzesz=F3tko 2014/1/2 Stefan Monnier : >> The problem is that url-http.el sets a lot of headers by default that >> can not be overwritten in any other way then dynamically overshadowing >> some variables. > > Indeed, this is ugly. Improvements welcome. > >> For example, all connections are keep-alive by >> default, which is confusing in itself already, > > Not sure why it should be a problem. > >> (let ((url-request-method "GET") >> (url-request-extra-headers '(("Connection" . "close")))) >> (url-retrieve-synchronously "http://www.google.com/")) >> And what is sent is this: >> GET / HTTP/1.1 >> Connection: keep-alive >> ... >> Connection: close > >> Which again isn't valid HTTP and the behaviour of the HTTP server in >> this case is undefined and implementation specific. The only way to >> workaround this is doing this: > >> (let ((url-http-attempt-keepalives nil) >> (url-request-method "GET") >> (url-request-extra-headers '(("Connection" . "close")))) >> (url-retrieve-synchronously "http://www.google.com/")) > > Yuck! We can probably fix this fairly easily by letting > url-request-extra-headers override (rather than just add to) > other headers. > >> This is all the more irritating so many of the headers are set by >> default using the variables url-vars.el. Why those things are at all >> variables is a mystery to me. > > Probably partly historical evolution (there was no place to add new > "parameters", so adding dynamic vars was an easy way to add more control > without breaking existing code). > >> In the end it is much easier to do HTTP requests manually using >> make-network-process then it is with the url library, > > I think that's misleading: the URL library is supposed to deal with > things like proxies and redirections, which "manual requests via > make-network-process" probably won't handle. > >> Didn't anyone else run into problems with it? > > Apparently not yet. But I agree that the API might deserve a redesign > (IIRC another problem is in the way headers in the answer are returned > to the caller, which does not work consistently across different kinds > of URLs (ftp, http, file, imap, ...)). > > > Stefan --001a113675249281ec04ef14c493 Content-Type: text/x-patch; charset=UTF-8; name="url.patch" Content-Disposition: attachment; filename="url.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hpzr8afu0 PT09IG1vZGlmaWVkIGZpbGUgJ2xpc3Avc3Vici5lbCcKLS0tIG9sZC9saXNwL3N1YnIuZWwJMjAx NC0wMS0wMSAwNzo0MzozNCArMDAwMAorKysgbmV3L2xpc3Avc3Vici5lbAkyMDE0LTAxLTAzIDE3 OjU3OjE0ICswMDAwCkBAIC00NjQsNiArNDY0LDMwIEBACiAJICAgIChhc2V0IHRyZWUgaSAoY29w eS10cmVlIChhcmVmIHRyZWUgaSkgdmVjcCkpKQogCSAgdHJlZSkKICAgICAgIHRyZWUpKSkKKwor KGRlZnVuIG1lcmdlLWFsaXN0cyAoYWxpczEgYWxpczIga2V5Y21wKQorICAiTWVyZ2VzIGFsaXN0 cyBBTElTMSBhbmQgQUxJUzIsIG5vbi1kZXN0cnVjdGl2ZWx5LCByZXR1cm5pbmcKKyAgYW5vdGhl ciBhbGlzdCwgY29udGFpbmluZyB0aGUga2V5cyBmcm9tIGJvdGggQUxJUzEgYW5kIEFMSVMyLAor ICB3aXRoIHZhbHVlcyBmcm9tIEFMSVMyIHRha2luZyBwcmVjZWRlbmNlLiBGb3IgZWZmaWNpZW5j eSwgYQorICBjb21wYXJpc2lvbiBmdW5jdGlvbiBLRVlDTVAgaGF2ZSB0byBiZSBzdXBwbGllZCwg dGhlIGxpc3RzIHdpbGwKKyAgYmUgc29ydGVkIGFuZCB0aGVuIG1lcmdlZCBieSBoYXZpbmcgdHdv IHBvaW50ZXJzIHRyYXZlcnNlIHRoZQorICB0d28gbGlzdHMgc2ltdWxhdGVuZW91c2x5LiIKKyAg KGxldCAoKGFsaXN0MSAoc29ydCAoY29weS1saXN0IGFsaXMxKSBrZXljbXApKQorICAgICAgICAo YWxpc3QyIChzb3J0IChjb3B5LWxpc3QgYWxpczIpIGtleWNtcCkpCisgICAgICAgIChyZXMgKGxp c3QpKSkKKyAgICAod2hpbGUgKGFuZCBhbGlzdDEgYWxpc3QyKQorICAgICAgKGNvbmQgKChlcXVh bCAoY2FyIChjYXIgYWxpc3QxKSkgKGNhciAoY2FyIGFsaXN0MikpKQorICAgICAgICAgICAgIChw dXNoIChjYXIgYWxpc3QxKSByZXMpCisgICAgICAgICAgICAgKHNldHEgYWxpc3QxIChjZHIgYWxp c3QxKSkKKyAgICAgICAgICAgICAoc2V0cSBhbGlzdDIgKGNkciBhbGlzdDIpKSkKKyAgICAgICAg ICAgICgoZnVuY2FsbCBrZXljbXAgKGNhciBhbGlzdDEpIChjYXIgYWxpc3QyKSkKKyAgICAgICAg ICAgICAocHVzaCAoY2FyIGFsaXN0MSkgcmVzKQorICAgICAgICAgICAgIChzZXRxIGFsaXN0MSAo Y2RyIGFsaXN0MSkpKQorICAgICAgICAgICAgKHQKKyAgICAgICAgICAgICAocHVzaCAoY2FyIGFs aXN0MikgcmVzKQorICAgICAgICAgICAgIChzZXRxIGFsaXN0MiAoY2RyIGFsaXN0MikpKSkpCisg ICAgKG5jb25jIHJlcyBhbGlzdDEgYWxpc3QyKSkpCisKIAwKIDs7OzsgVmFyaW91cyBsaXN0LXNl YXJjaCBmdW5jdGlvbnMuCiAKCj09PSBtb2RpZmllZCBmaWxlICdsaXNwL3VybC91cmwtY29va2ll LmVsJwotLS0gb2xkL2xpc3AvdXJsL3VybC1jb29raWUuZWwJMjAxNC0wMS0wMSAwNzo0MzozNCAr MDAwMAorKysgbmV3L2xpc3AvdXJsL3VybC1jb29raWUuZWwJMjAxNC0wMS0wMyAxNzo1MDowOCAr MDAwMApAQCAtMjA4LDYgKzIwOCw3IEBACiAJCSAgICAgKGlmIHJldHZhbAogCQkJIChjb25jYXQg cmV0dmFsICI7ICIgY2h1bmspCiAJCSAgICAgICAoY29uY2F0ICJDb29raWU6ICIgY2h1bmspKSkp KQorICAgIChtZXNzYWdlIChwcmluMS10by1zdHJpbmcgcmV0dmFsKSkKICAgICAoaWYgcmV0dmFs CiAJKGNvbmNhdCByZXR2YWwgIlxyXG4iKQogICAgICAgIiIpKSkKCj09PSBtb2RpZmllZCBmaWxl ICdsaXNwL3VybC91cmwtaHR0cC5lbCcKLS0tIG9sZC9saXNwL3VybC91cmwtaHR0cC5lbAkyMDE0 LTAxLTAxIDA3OjQzOjM0ICswMDAwCisrKyBuZXcvbGlzcC91cmwvdXJsLWh0dHAuZWwJMjAxNC0w MS0wMyAxODowNDowMyArMDAwMApAQCAtMjA5LDIwICsyMDksMjMgQEAKIAkodXJsLWh0dHAtbWFy ay1jb25uZWN0aW9uLWFzLWJ1c3kgaG9zdCBwb3J0IGNvbm5lY3Rpb24pKSkpCiAKIDs7IEJ1aWxk aW5nIGFuIEhUVFAgcmVxdWVzdAotKGRlZnVuIHVybC1odHRwLXVzZXItYWdlbnQtc3RyaW5nICgp CisoZGVmdW4gdXJsLWh0dHAtdXNlci1hZ2VudCAoKQogICAoaWYgKG9yIChlcSB1cmwtcHJpdmFj eS1sZXZlbCAncGFyYW5vaWQpCiAJICAoYW5kIChsaXN0cCB1cmwtcHJpdmFjeS1sZXZlbCkKIAkg ICAgICAgKG1lbXEgJ2FnZW50IHVybC1wcml2YWN5LWxldmVsKSkpCi0gICAgICAiIgotICAgIChm b3JtYXQgIlVzZXItQWdlbnQ6ICVzVVJMLyVzXHJcbiIKLQkgICAgKGlmIHVybC1wYWNrYWdlLW5h bWUKLQkJKGNvbmNhdCB1cmwtcGFja2FnZS1uYW1lICIvIiB1cmwtcGFja2FnZS12ZXJzaW9uICIg IikKLQkgICAgICAiIikKLQkgICAgdXJsLXZlcnNpb24pKSkKKyAgICAgICcoKQorICAgIGAoKCJV c2VyLWFnZW50IiAuCisgICAgICAgLChmb3JtYXQgIiVzVVJMLyVzIgorICAgICAgICAgICAgICAg IChpZiB1cmwtcGFja2FnZS1uYW1lCisgICAgICAgICAgICAgICAgICAgIChjb25jYXQgdXJsLXBh Y2thZ2UtbmFtZSAiLyIgdXJsLXBhY2thZ2UtdmVyc2lvbiAiICIpCisgICAgICAgICAgICAgICAg ICAiIikKKyAgICAgICAgICAgICAgICB1cmwtdmVyc2lvbikpKSkpCiAKIChkZWZ1biB1cmwtaHR0 cC1jcmVhdGUtcmVxdWVzdCAoJm9wdGlvbmFsIHJlZi11cmwpCiAgICJDcmVhdGUgYW4gSFRUUCBy ZXF1ZXN0IGZvciBgdXJsLWh0dHAtdGFyZ2V0LXVybCcsIHJlZmVycmVkIHRvIGJ5IFJFRi1VUkwu IgotICAobGV0KiAoKGV4dHJhLWhlYWRlcnMpCisgIChsZXQqICgoZGVmYXVsdC1oZWFkZXJzKQor ICAgICAgICAgKGV4dHJhLWhlYWRlcnMpCisgICAgICAgICAoaGVhZGVycy1zdHJpbmcpCiAJIChy ZXF1ZXN0IG5pbCkKIAkgKG5vLWNhY2hlIChjZHItc2FmZSAoYXNzb2MgIlByYWdtYSIgdXJsLWh0 dHAtZXh0cmEtaGVhZGVycykpKQogCSAodXNpbmctcHJveHkgdXJsLWh0dHAtcHJveHkpCkBAIC0y MzUsMTkgKzIzOCwxMyBAQAogCQkJICh1cmwtZ2V0LWF1dGhlbnRpY2F0aW9uIHVybC1odHRwLXBy b3h5IG5pbCAnYW55IG5pbCkpKSkKIAkgKHJlYWwtZm5hbWUgKHVybC1maWxlbmFtZSB1cmwtaHR0 cC10YXJnZXQtdXJsKSkKIAkgKGhvc3QgKHVybC1ob3N0IHVybC1odHRwLXRhcmdldC11cmwpKQot CSAoYXV0aCAoaWYgKGNkci1zYWZlIChhc3NvYyAiQXV0aG9yaXphdGlvbiIgdXJsLWh0dHAtZXh0 cmEtaGVhZGVycykpCi0JCSAgIG5pbAotCQkgKHVybC1nZXQtYXV0aGVudGljYXRpb24gKG9yCi0J CQkJCSAgKGFuZCAoYm91bmRwICdwcm94eS1pbmZvKQotCQkJCQkgICAgICAgcHJveHktaW5mbykK LQkJCQkJICB1cmwtaHR0cC10YXJnZXQtdXJsKSBuaWwgJ2FueSBuaWwpKSkpCisJIChhdXRoICh1 cmwtZ2V0LWF1dGhlbnRpY2F0aW9uIChvcgorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIChhbmQgKGJvdW5kcCAncHJveHktaW5mbykKKyAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHByb3h5LWluZm8pCisgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgdXJsLWh0dHAtdGFyZ2V0LXVybCkgbmlsICdhbnkgbmlsKSkp CiAgICAgKGlmIChlcXVhbCAiIiByZWFsLWZuYW1lKQogCShzZXRxIHJlYWwtZm5hbWUgIi8iKSkK ICAgICAoc2V0cSBuby1jYWNoZSAoYW5kIG5vLWNhY2hlIChzdHJpbmctbWF0Y2ggIm5vLWNhY2hl IiBuby1jYWNoZSkpKQotICAgIChpZiBhdXRoCi0JKHNldHEgYXV0aCAoY29uY2F0ICJBdXRob3Jp emF0aW9uOiAiIGF1dGggIlxyXG4iKSkpCi0gICAgKGlmIHByb3h5LWF1dGgKLQkoc2V0cSBwcm94 eS1hdXRoIChjb25jYXQgIlByb3h5LUF1dGhvcml6YXRpb246ICIgcHJveHktYXV0aCAiXHJcbiIp KSkKIAogICAgIDs7IFByb3RlY3Rpb24gYWdhaW5zdCBzdHVwaWQgdmFsdWVzIGluIHRoZSByZWZl cnJlcgogICAgIChpZiAoYW5kIHJlZi11cmwgKHN0cmluZ3AgcmVmLXVybCkgKG9yIChzdHJpbmc9 IHJlZi11cmwgImZpbGU6bmlsIikKQEAgLTI2MCwxNCArMjU3LDU2IEBACiAJCSAobWVtcSAnbGFz dGxvYyB1cmwtcHJpdmFjeS1sZXZlbCkpKQogCShzZXRxIHJlZi11cmwgbmlsKSkKIAotICAgIDs7 IHVybC1odHRwLWV4dHJhLWhlYWRlcnMgY29udGFpbnMgYW4gYXNzb2MtbGlzdCBvZgotICAgIDs7 IGhlYWRlci92YWx1ZSBwYWlycyB0aGF0IHdlIG5lZWQgdG8gcHV0IGludG8gdGhlIHJlcXVlc3Qu Ci0gICAgKHNldHEgZXh0cmEtaGVhZGVycyAobWFwY29uY2F0Ci0JCQkgKGxhbWJkYSAoeCkKLQkJ CSAgIChjb25jYXQgKGNhciB4KSAiOiAiIChjZHIgeCkpKQotCQkJIHVybC1odHRwLWV4dHJhLWhl YWRlcnMgIlxyXG4iKSkKLSAgICAoaWYgKG5vdCAoZXF1YWwgZXh0cmEtaGVhZGVycyAiIikpCi0J KHNldHEgZXh0cmEtaGVhZGVycyAoY29uY2F0IGV4dHJhLWhlYWRlcnMgIlxyXG4iKSkpCisgICAg OzsgRGVmYXVsdC1oZWFkZXJzIGFuZCB1cmwtaHR0cC1leHRyYS1oZWFkZXJzIGFyZSBib3RoIGFs aXN0cyBvZgorICAgIDs7IGhlYWRlci92YWx1ZSBwYWlycworICAgIChzZXRxIGRlZmF1bHQtaGVh ZGVycworICAgICAgICAgIGAoKCJDb25uZWN0aW9uIiAuICwoaWYgKG9yIHVzaW5nLXByb3h5Cisg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKG5vdCB1cmwtaHR0cC1hdHRlbXB0 LWtlZXBhbGl2ZXMpKQorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgImNsb3NlIiAi a2VlcC1hbGl2ZSIpKQorICAgICAgICAgICAgKCJIb3N0IiAuICwoaWYgKC89ICh1cmwtcG9ydCB1 cmwtaHR0cC10YXJnZXQtdXJsKQorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICh1cmwt c2NoZW1lLWdldC1wcm9wZXJ0eQorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAodXJs LXR5cGUgdXJsLWh0dHAtdGFyZ2V0LXVybCkgJ2RlZmF1bHQtcG9ydCkpCisgICAgICAgICAgICAg ICAgICAgICAgICAgICAoZm9ybWF0ICIlczolZCIgaG9zdCAodXJsLXBvcnQgdXJsLWh0dHAtdGFy Z2V0LXVybCkpCisgICAgICAgICAgICAgICAgICAgICAgICAgaG9zdCkpCisgICAgICAgICAgICAo Ik1JTUUtVmVyc2lvbiIgLiAiMS4wIikKKyAgICAgICAgICAgICgiQWNjZXB0IiAuICwob3IgdXJs LW1pbWUtYWNjZXB0LXN0cmluZyAiKi8qIikpICAgICAgICAgICAgCisgICAgICAgICAgICAsQCh3 aGVuIChhbmQgKG5vdCBuby1jYWNoZSkKKyAgICAgICAgICAgICAgICAgICAgICAgICAobWVtYmVy IHVybC1odHRwLW1ldGhvZCAnKCJHRVQiIG5pbCkpKQorICAgICAgICAgICAgICAgIChsZXQgKCh0 bSAodXJsLWlzLWNhY2hlZCB1cmwtaHR0cC10YXJnZXQtdXJsKSkpCisgICAgICAgICAgICAgICAg ICAoaWYgdG0KKyAgICAgICAgICAgICAgICAgICAgICBgKCgiSWYtbW9kaWZpZWQtc2luY2UiIC4g LCh1cmwtZ2V0LW5vcm1hbGl6ZWQtZGF0ZSB0bSkpKSkpKQorICAgICAgICAgICAgLEAod2hlbiBy ZWYtdXJsCisgICAgICAgICAgICAgICAgYCgoIlJlZmVyZXIiIC4gLHJlZi11cmwpKSkKKyAgICAg ICAgICAgICxAKHdoZW4gdXJsLXBlcnNvbmFsLW1haWwtYWRkcmVzcworICAgICAgICAgICAgICAg IGAoKCJGcm9tIiAuICx1cmwtcGVyc29uYWwtbWFpbC1hZGRyZXNzKSkpCisgICAgICAgICAgICAs QCh3aGVuIHVybC1taW1lLWVuY29kaW5nLXN0cmluZworICAgICAgICAgICAgICAgIGAoKCJBY2Nl cHQtZW5jb2RpbmciIC4gLHVybC1taW1lLWVuY29kaW5nLXN0cmluZykpKQorICAgICAgICAgICAg LEAod2hlbiB1cmwtbWltZS1jaGFyc2V0LXN0cmluZworICAgICAgICAgICAgICAgIGAoKCJBY2Nl cHQtY2hhcnNldCIgLiAsdXJsLW1pbWUtY2hhcnNldC1zdHJpbmcpKSkKKyAgICAgICAgICAgICxA KHdoZW4gdXJsLW1pbWUtbGFuZ3VhZ2Utc3RyaW5nCisgICAgICAgICAgICAgICAgYCgoIkFjY2Vw dC1sYW5ndWFnZSIgLiAsdXJsLW1pbWUtbGFuZ3VhZ2Utc3RyaW5nKSkpCisgICAgICAgICAgICAs QCh3aGVuIGF1dGgKKyAgICAgICAgICAgICAgICBgKCgiQXV0aG9yaXphdGlvbiIgLiAsYXV0aCkp KQorICAgICAgICAgICAgLEAod2hlbiBwcm94eS1hdXRoCisgICAgICAgICAgICAgICAgYCgoIlBy b3h5LUF1dGhvcml6YXRpb24iIC4gLHByb3h5LWF1dGgpKSkKKyAgICAgICAgICAgICxAKHdoZW4g dXJsLWh0dHAtZGF0YQorICAgICAgICAgICAgICAgIGAoKCJDb250ZW50LWxlbmd0aCIgLiAsKG51 bWJlci10by1zdHJpbmcgKGxlbmd0aCB1cmwtaHR0cC1kYXRhKSkpKSkKKyAgICAgICAgICAgICxA KHdoZW4gdXJsLWV4dGVuc2lvbnMtaGVhZGVyCisgICAgICAgICAgICAgICAgYCgoIkV4dGVuc2lv biIgLiAsdXJsLWV4dGVuc2lvbnMtaGVhZGVyKSkpCisgICAgICAgICAgICAsQCh1cmwtaHR0cC11 c2VyLWFnZW50KSkpCisKKyAgICA7OzsgdXJsLWh0dHAtZXh0cmEtaGVhZGVycyBhcmUgbWVyZ2Vk IG9uIHRvcCBkZWZhdWx0LWhlYWRlcnMsIGFueQorICAgIDs7OyBoZWFkZXJzIHNwZWNpZmllZCBp biBib3RoIHdpbGwgYmUgc2VudCBhcyBwZXIgdmFsdWUgaW4KKyAgICA7OzsgdXJsLWh0dHAtZXh0 cmEtaGVhZGVycworICAgIChzZXRxIGhlYWRlcnMtc3RyaW5nCisgICAgICAgICAgKGNvbmNhdAor ICAgICAgICAgICAobWFwY29uY2F0CisgICAgICAgICAgICAobGFtYmRhICh4KQorICAgICAgICAg ICAgICAoY29uY2F0IChjYXIgeCkgIjogIiAoY2RyIHgpKSkKKyAgICAgICAgICAgIChtZXJnZS1h bGlzdHMgZGVmYXVsdC1oZWFkZXJzIHVybC1odHRwLWV4dHJhLWhlYWRlcnMKKyAgICAgICAgICAg ICAgICAgICAgICAgICAgKGxhbWJkYSAoYSBiKSAoc3RyaW5nLWxlc3NwIChjYXIgYSkgKGNhciBi KSkpKQorICAgICAgICAgICAgIlxyXG4iKQorICAgICAgICAgICAiXHJcbiIpKQogCiAgICAgOzsg VGhpcyB3YXMgZG9uZSB3aXRoIGEgY2FsbCB0byBgZm9ybWF0Jy4gIENvbmNhdGVuYXRpbmcgcGFy dHMgaGFzCiAgICAgOzsgdGhlIGFkdmFudGFnZSBvZiBrZWVwaW5nIHRoZSBwYXJ0cyBvZiBlYWNo IGhlYWRlciB0b2dldGhlciBhbmQKQEAgLTI4Nyw3OCArMzI2LDIxIEBACiAgICAgICAgICAgICdz dHJpbmctYXMtdW5pYnl0ZQogICAgICAgICAgICAoZGVscSBuaWwKICAgICAgICAgICAgIChsaXN0 Ci0gICAgICAgICAgICAgOzsgVGhlIHJlcXVlc3QKKyAgICAgICAgICAgICA7OyBUaGUgcmVxdWVz dCBsaW5lCiAgICAgICAgICAgICAgKG9yIHVybC1odHRwLW1ldGhvZCAiR0VUIikgIiAiCiAgICAg ICAgICAgICAgKGlmIHVzaW5nLXByb3h5ICh1cmwtcmVjcmVhdGUtdXJsIHVybC1odHRwLXRhcmdl dC11cmwpIHJlYWwtZm5hbWUpCiAgICAgICAgICAgICAgIiBIVFRQLyIgdXJsLWh0dHAtdmVyc2lv biAiXHJcbiIKLSAgICAgICAgICAgICA7OyBWZXJzaW9uIG9mIE1JTUUgd2Ugc3BlYWsKLSAgICAg ICAgICAgICAiTUlNRS1WZXJzaW9uOiAxLjBcclxuIgotICAgICAgICAgICAgIDs7IChtYXliZSkg VHJ5IHRvIGtlZXAgdGhlIGNvbm5lY3Rpb24gb3BlbgotICAgICAgICAgICAgICJDb25uZWN0aW9u OiAiIChpZiAob3IgdXNpbmctcHJveHkKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIChub3QgdXJsLWh0dHAtYXR0ZW1wdC1rZWVwYWxpdmVzKSkKLSAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgImNsb3NlIiAia2VlcC1hbGl2ZSIpICJcclxuIgotICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICA7OyBIVFRQIGV4dGVuc2lvbnMgd2Ugc3VwcG9ydAotICAgICAg ICAgICAgIChpZiB1cmwtZXh0ZW5zaW9ucy1oZWFkZXIKLSAgICAgICAgICAgICAgICAgKGZvcm1h dAotICAgICAgICAgICAgICAgICAgIkV4dGVuc2lvbjogJXNcclxuIiB1cmwtZXh0ZW5zaW9ucy1o ZWFkZXIpKQotICAgICAgICAgICAgIDs7IFdobyB3ZSB3YW50IHRvIHRhbGsgdG8KLSAgICAgICAg ICAgICAoaWYgKC89ICh1cmwtcG9ydCB1cmwtaHR0cC10YXJnZXQtdXJsKQotICAgICAgICAgICAg ICAgICAgICAgKHVybC1zY2hlbWUtZ2V0LXByb3BlcnR5Ci0gICAgICAgICAgICAgICAgICAgICAg KHVybC10eXBlIHVybC1odHRwLXRhcmdldC11cmwpICdkZWZhdWx0LXBvcnQpKQotICAgICAgICAg ICAgICAgICAoZm9ybWF0Ci0gICAgICAgICAgICAgICAgICAiSG9zdDogJXM6JWRcclxuIiBob3N0 ICh1cmwtcG9ydCB1cmwtaHR0cC10YXJnZXQtdXJsKSkKLSAgICAgICAgICAgICAgIChmb3JtYXQg Ikhvc3Q6ICVzXHJcbiIgaG9zdCkpCi0gICAgICAgICAgICAgOzsgV2hvIGl0cyBmcm9tCi0gICAg ICAgICAgICAgKGlmIHVybC1wZXJzb25hbC1tYWlsLWFkZHJlc3MKLSAgICAgICAgICAgICAgICAg KGNvbmNhdAotICAgICAgICAgICAgICAgICAgIkZyb206ICIgdXJsLXBlcnNvbmFsLW1haWwtYWRk cmVzcyAiXHJcbiIpKQotICAgICAgICAgICAgIDs7IEVuY29kaW5ncyB3ZSB1bmRlcnN0YW5kCi0g ICAgICAgICAgICAgKGlmIHVybC1taW1lLWVuY29kaW5nLXN0cmluZwotICAgICAgICAgICAgICAg ICAoY29uY2F0Ci0gICAgICAgICAgICAgICAgICAiQWNjZXB0LWVuY29kaW5nOiAiIHVybC1taW1l LWVuY29kaW5nLXN0cmluZyAiXHJcbiIpKQotICAgICAgICAgICAgIChpZiB1cmwtbWltZS1jaGFy c2V0LXN0cmluZwotICAgICAgICAgICAgICAgICAoY29uY2F0Ci0gICAgICAgICAgICAgICAgICAi QWNjZXB0LWNoYXJzZXQ6ICIgdXJsLW1pbWUtY2hhcnNldC1zdHJpbmcgIlxyXG4iKSkKLSAgICAg ICAgICAgICA7OyBMYW5ndWFnZXMgd2UgdW5kZXJzdGFuZAotICAgICAgICAgICAgIChpZiB1cmwt bWltZS1sYW5ndWFnZS1zdHJpbmcKLSAgICAgICAgICAgICAgICAgKGNvbmNhdAotICAgICAgICAg ICAgICAgICAgIkFjY2VwdC1sYW5ndWFnZTogIiB1cmwtbWltZS1sYW5ndWFnZS1zdHJpbmcgIlxy XG4iKSkKLSAgICAgICAgICAgICA7OyBUeXBlcyB3ZSB1bmRlcnN0YW5kCi0gICAgICAgICAgICAg IkFjY2VwdDogIiAob3IgdXJsLW1pbWUtYWNjZXB0LXN0cmluZyAiKi8qIikgIlxyXG4iCi0gICAg ICAgICAgICAgOzsgVXNlciBhZ2VudAotICAgICAgICAgICAgICh1cmwtaHR0cC11c2VyLWFnZW50 LXN0cmluZykKLSAgICAgICAgICAgICA7OyBQcm94eSBBdXRob3JpemF0aW9uCi0gICAgICAgICAg ICAgcHJveHktYXV0aAotICAgICAgICAgICAgIDs7IEF1dGhvcml6YXRpb24KLSAgICAgICAgICAg ICBhdXRoCisgICAgICAgICAgICAgOzsgSGVhZGVycworICAgICAgICAgICAgIGhlYWRlcnMtc3Ry aW5nCiAgICAgICAgICAgICAgOzsgQ29va2llcwotCSAgICAgKHdoZW4gKHVybC11c2UtY29va2ll cyB1cmwtaHR0cC10YXJnZXQtdXJsKQotCSAgICAgICAodXJsLWNvb2tpZS1nZW5lcmF0ZS1oZWFk ZXItbGluZXMKLQkJaG9zdCByZWFsLWZuYW1lCi0JCShlcXVhbCAiaHR0cHMiICh1cmwtdHlwZSB1 cmwtaHR0cC10YXJnZXQtdXJsKSkpKQotICAgICAgICAgICAgIDs7IElmLW1vZGlmaWVkLXNpbmNl Ci0gICAgICAgICAgICAgKGlmIChhbmQgKG5vdCBuby1jYWNoZSkKLSAgICAgICAgICAgICAgICAg ICAgICAobWVtYmVyIHVybC1odHRwLW1ldGhvZCAnKCJHRVQiIG5pbCkpKQotICAgICAgICAgICAg ICAgICAobGV0ICgodG0gKHVybC1pcy1jYWNoZWQgdXJsLWh0dHAtdGFyZ2V0LXVybCkpKQotICAg ICAgICAgICAgICAgICAgIChpZiB0bQotICAgICAgICAgICAgICAgICAgICAgICAoY29uY2F0ICJJ Zi1tb2RpZmllZC1zaW5jZTogIgotICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICh1cmwt Z2V0LW5vcm1hbGl6ZWQtZGF0ZSB0bSkgIlxyXG4iKSkpKQotICAgICAgICAgICAgIDs7IFdoZW5j ZSB3ZSBjYW1lCi0gICAgICAgICAgICAgKGlmIHJlZi11cmwgKGNvbmNhdAotICAgICAgICAgICAg ICAgICAgICAgICAgICAiUmVmZXJlcjogIiByZWYtdXJsICJcclxuIikpCi0gICAgICAgICAgICAg ZXh0cmEtaGVhZGVycwotICAgICAgICAgICAgIDs7IExlbmd0aCBvZiBkYXRhCi0gICAgICAgICAg ICAgKGlmIHVybC1odHRwLWRhdGEKLSAgICAgICAgICAgICAgICAgKGNvbmNhdAotICAgICAgICAg ICAgICAgICAgIkNvbnRlbnQtbGVuZ3RoOiAiIChudW1iZXItdG8tc3RyaW5nCi0gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIChsZW5ndGggdXJsLWh0dHAtZGF0YSkpCi0gICAg ICAgICAgICAgICAgICAiXHJcbiIpKQotICAgICAgICAgICAgIDs7IEVuZCByZXF1ZXN0CisgICAg ICAgICAgICAgKHdoZW4gKHVybC11c2UtY29va2llcyB1cmwtaHR0cC10YXJnZXQtdXJsKQorICAg ICAgICAgICAgICAgKHVybC1jb29raWUtZ2VuZXJhdGUtaGVhZGVyLWxpbmVzCisgICAgICAgICAg ICAgICAgaG9zdCByZWFsLWZuYW1lCisgICAgICAgICAgICAgICAgKGVxdWFsICJodHRwcyIgKHVy bC10eXBlIHVybC1odHRwLXRhcmdldC11cmwpKSkpCisgICAgICAgICAgICAgOzsgRW5kIG9mIGhl YWRlcnMKICAgICAgICAgICAgICAiXHJcbiIKLSAgICAgICAgICAgICA7OyBBbnkgZGF0YQotICAg ICAgICAgICAgIHVybC1odHRwLWRhdGEKLQkgICAgIDs7IElmIGB1cmwtaHR0cC1kYXRhJyBpcyBu aWwsIGF2b2lkIHR3byBDUkxGcyAoQnVnIzg5MzEpLgotCSAgICAgKGlmIHVybC1odHRwLWRhdGEg IlxyXG4iKSkpCisgICAgICAgICAgICAgOzsgRGF0YQorICAgICAgICAgICAgIHVybC1odHRwLWRh dGEpKQogICAgICAgICAgICAiIikpCiAgICAgKHVybC1odHRwLWRlYnVnICJSZXF1ZXN0IGlzOiBc biVzIiByZXF1ZXN0KQogICAgIHJlcXVlc3QpKQoKPT09IGFkZGVkIGZpbGUgJ3Rlc3QvYXV0b21h dGVkL3VybC1odHRwLXRlc3RzLmVsJwotLS0gb2xkL3Rlc3QvYXV0b21hdGVkL3VybC1odHRwLXRl c3RzLmVsCTE5NzAtMDEtMDEgMDA6MDA6MDAgKzAwMDAKKysrIG5ldy90ZXN0L2F1dG9tYXRlZC91 cmwtaHR0cC10ZXN0cy5lbAkyMDE0LTAxLTAzIDE4OjA2OjIxICswMDAwCkBAIC0wLDAgKzEsMTAw IEBACis7OzsgdXJsLWh0dHAuZWwgLS0tIFRlc3Qgc3VpdGUgZm9yIHVybC1odHRwLgorCis7OyBD b3B5cmlnaHQgKEMpIDIwMTEtMjAxNCBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb24sIEluYy4KKwor OzsgQXV0aG9yOiBKYXJvc8WCYXcgUnplc3rDs3RrbyA8anJ6ZXN6b3Rrb0BnbWFpbC5jb20+Cis7 OyBLZXl3b3JkczogZGF0YQorCis7OyBUaGlzIGZpbGUgaXMgcGFydCBvZiBHTlUgRW1hY3MuCisK Kzs7IEdOVSBFbWFjcyBpcyBmcmVlIHNvZnR3YXJlOiB5b3UgY2FuIHJlZGlzdHJpYnV0ZSBpdCBh bmQvb3IgbW9kaWZ5Cis7OyBpdCB1bmRlciB0aGUgdGVybXMgb2YgdGhlIEdOVSBHZW5lcmFsIFB1 YmxpYyBMaWNlbnNlIGFzIHB1Ymxpc2hlZCBieQorOzsgdGhlIEZyZWUgU29mdHdhcmUgRm91bmRh dGlvbiwgZWl0aGVyIHZlcnNpb24gMyBvZiB0aGUgTGljZW5zZSwgb3IKKzs7IChhdCB5b3VyIG9w dGlvbikgYW55IGxhdGVyIHZlcnNpb24uCisKKzs7IEdOVSBFbWFjcyBpcyBkaXN0cmlidXRlZCBp biB0aGUgaG9wZSB0aGF0IGl0IHdpbGwgYmUgdXNlZnVsLAorOzsgYnV0IFdJVEhPVVQgQU5ZIFdB UlJBTlRZOyB3aXRob3V0IGV2ZW4gdGhlIGltcGxpZWQgd2FycmFudHkgb2YKKzs7IE1FUkNIQU5U QUJJTElUWSBvciBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4gIFNlZSB0aGUKKzs7 IEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGZvciBtb3JlIGRldGFpbHMuCisKKzs7IFlvdSBz aG91bGQgaGF2ZSByZWNlaXZlZCBhIGNvcHkgb2YgdGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNl bnNlCis7OyBhbG9uZyB3aXRoIEdOVSBFbWFjcy4gIElmIG5vdCwgc2VlIDxodHRwOi8vd3d3Lmdu dS5vcmcvbGljZW5zZXMvPi4KKworOzs7IENvZGU6CisKKyhyZXF1aXJlICdlcnQpCisocmVxdWly ZSAndXJsLWZ1dHVyZSkKKworKGVydC1kZWZ0ZXN0IHVybC1odHRwLWNyZWF0ZS1yZXF1ZXN0L2Ny ZWF0ZXMtdmFsaWQtaHR0cC1nZXQtcmVxdWVzdCAoKQorICAobGV0KiAoKHVybC1odHRwLWV4dHJh LWhlYWRlcnMpCisgICAgICAgICAodXJsLWh0dHAtcHJveHkgbmlsKSAgICAgIAorICAgICAgICAg KHVybC1odHRwLW1ldGhvZCAiR0VUIikKKyAgICAgICAgICh1cmwtaHR0cC10YXJnZXQtdXJsICh1 cmwtZ2VuZXJpYy1wYXJzZS11cmwgImh0dHA6Ly93d3cuZ251Lm9yZy8iKSkKKyAgICAgICAgICh1 cmwtaHR0cC1kYXRhKQorICAgICAgICAgKHVybC1wYWNrYWdlLW5hbWUgIlhZWiIpCisgICAgICAg ICAodXJsLXBhY2thZ2UtdmVyc2lvbiAiMi4wIikpCisgICAgKHdpdGgtdGVtcC1idWZmZXIKKyAg ICAgIChpbnNlcnQgKHVybC1odHRwLWNyZWF0ZS1yZXF1ZXN0KSkKKyAgICAgIChnb3RvLWNoYXIg KHBvaW50LW1pbikpCisgICAgICAoc2hvdWxkIChsb29raW5nLWF0ICJHRVQgLyBIVFRQLzEuMVxy XG4iKSkKKyAgICAgIChzaG91bGQgKHNlYXJjaC1mb3J3YXJkICJBY2NlcHQ6ICovKlxyXG4iKSkK KyAgICAgIChzaG91bGQgKHNlYXJjaC1mb3J3YXJkICJIb3N0OiB3d3cuZ251Lm9yZ1xyXG4iKSkK KyAgICAgIChzaG91bGQgKHNlYXJjaC1mb3J3YXJkICJVc2VyLWFnZW50OiBYWVovMi4wIFVSTC9F bWFjc1xyXG4iKSkpKSkKKworKGVydC1kZWZ0ZXN0IHVybC1odHRwLWNyZWF0ZS1yZXF1ZXN0L3Nl bmRzLXNpbmdsZWxpbmUtaHR0cC1jb29raWVzICgpCisgIChsZXQqICgodXJsLWh0dHAtZXh0cmEt aGVhZGVycykKKyAgICAgICAgICh1cmwtaHR0cC1wcm94eSBuaWwpICAgICAgCisgICAgICAgICAo dXJsLWh0dHAtbWV0aG9kICJHRVQiKQorICAgICAgICAgKHVybC1odHRwLXRhcmdldC11cmwgKHVy bC1nZW5lcmljLXBhcnNlLXVybCAiaHR0cDovL3d3dy51cmwtaHR0cC10ZXN0LWhvc3QuY29tLyIp KQorICAgICAgICAgKHVybC1odHRwLWRhdGEpCisgICAgICAgICAodXJsLWNvb2tpZS1tdWx0aXBs ZS1saW5lIG5pbCkpCisgICAgKHNldGYgKHVybC11c2UtY29va2llcyB1cmwtaHR0cC10YXJnZXQt dXJsKSB0KQorICAgIChzZXRxIHVybC1jb29raWUtc3RvcmFnZSBuaWwpCisgICAgKHVud2luZC1w cm90ZWN0CisgICAgICAgIChwcm9nbgorICAgICAgICAgICh1cmwtY29va2llLXN0b3JlICJ0ZXN0 MSIgInRlc3R2YWx1ZTF0ZXN0dmFsdWUxdGVzdHZhbHVlMXRlc3R2YWx1ZTF0ZXN0dmFsdWUxIiBu aWwgInd3dy51cmwtaHR0cC10ZXN0LWhvc3QuY29tIiAiLyIpCisgICAgICAgICAgKHVybC1jb29r aWUtc3RvcmUgInRlc3QyIiAidGVzdHZhbHVlMiIgbmlsICJ3d3cudXJsLWh0dHAtdGVzdC1ob3N0 LmNvbSIgIi8iKQorICAgICAgICAgICh3aXRoLXRlbXAtYnVmZmVyCisgICAgICAgICAgICAoaW5z ZXJ0ICh1cmwtaHR0cC1jcmVhdGUtcmVxdWVzdCkpCisgICAgICAgICAgICAoZ290by1jaGFyIChw b2ludC1taW4pKQorICAgICAgICAgICAgKHNob3VsZCAoc2VhcmNoLWZvcndhcmQgIkNvb2tpZTog dGVzdDE9dGVzdHZhbHVlMXRlc3R2YWx1ZTF0ZXN0dmFsdWUxdGVzdHZhbHVlMXRlc3R2YWx1ZTE7 IHRlc3QyPXRlc3R2YWx1ZTJcclxuIikpKSkKKyAgICAgIChzZXRxIHVybC1jb29raWUtc3RvcmFn ZSBuaWwpKSkpCisKKyhlcnQtZGVmdGVzdCB1cmwtaHR0cC1jcmVhdGUtcmVxdWVzdC9zZW5kcy1t dWx0aWxpbmUtaHR0cC1jb29raWVzICgpCisgIChsZXQqICgodXJsLWh0dHAtZXh0cmEtaGVhZGVy cykKKyAgICAgICAgICh1cmwtaHR0cC1wcm94eSBuaWwpICAgICAgCisgICAgICAgICAodXJsLWh0 dHAtbWV0aG9kICJHRVQiKQorICAgICAgICAgKHVybC1odHRwLXRhcmdldC11cmwgKHVybC1nZW5l cmljLXBhcnNlLXVybCAiaHR0cDovL3d3dy51cmwtaHR0cC10ZXN0LWhvc3QuY29tLyIpKQorICAg ICAgICAgKHVybC1odHRwLWRhdGEpCisgICAgICAgICAodXJsLWNvb2tpZS1tdWx0aXBsZS1saW5l IHQpCisgICAgICAgICAoY29va2llLXZhbHVlKSkKKyAgICAoc2V0ZiAodXJsLXVzZS1jb29raWVz IHVybC1odHRwLXRhcmdldC11cmwpIHQpCisgICAgKHNldHEgdXJsLWNvb2tpZS1zdG9yYWdlIG5p bCkKKyAgICAodW53aW5kLXByb3RlY3QKKyAgICAgICAgKHByb2duCisgICAgICAgICAgKHVybC1j b29raWUtc3RvcmUgInRlc3QxIiAidGVzdHZhbHVlMXRlc3R2YWx1ZTF0ZXN0dmFsdWUxdGVzdHZh bHVlMXRlc3R2YWx1ZTEiIG5pbCAid3d3LnVybC1odHRwLXRlc3QtaG9zdC5jb20iICIvIikKKyAg ICAgICAgICAodXJsLWNvb2tpZS1zdG9yZSAidGVzdDIiICJ0ZXN0dmFsdWUyIiBuaWwgInd3dy51 cmwtaHR0cC10ZXN0LWhvc3QuY29tIiAiLyIpCisgICAgICAgICAgKHdpdGgtdGVtcC1idWZmZXIK KyAgICAgICAgICAgIChpbnNlcnQgKHVybC1odHRwLWNyZWF0ZS1yZXF1ZXN0KSkKKyAgICAgICAg ICAgIChnb3RvLWNoYXIgKHBvaW50LW1pbikpCisgICAgICAgICAgICAoc2hvdWxkIChzZWFyY2gt Zm9yd2FyZCAiQ29va2llOiB0ZXN0MT10ZXN0dmFsdWUxdGVzdHZhbHVlMXRlc3R2YWx1ZTF0ZXN0 dmFsdWUxdGVzdHZhbHVlMVxyXG4iKSkKKyAgICAgICAgICAgIChzaG91bGQgKHNlYXJjaC1mb3J3 YXJkICJDb29raWU6IHRlc3QyPXRlc3R2YWx1ZTJcclxuIikpKSkKKyAgICAgIChzZXRxIHVybC1j b29raWUtc3RvcmFnZSBuaWwpKSkpCisKKyhlcnQtZGVmdGVzdCB1cmwtaHR0cC1jcmVhdGUtcmVx dWVzdC9jcmVhdGVzLXZhbGlkLWh0dHAtcG9zdC1yZXF1ZXN0ICgpCisgIChsZXQqICgodXJsLWh0 dHAtZXh0cmEtaGVhZGVycykKKyAgICAgICAgICh1cmwtaHR0cC1wcm94eSBuaWwpICAgICAgCisg ICAgICAgICAodXJsLWh0dHAtbWV0aG9kICJQT1NUIikKKyAgICAgICAgICh1cmwtaHR0cC10YXJn ZXQtdXJsICh1cmwtZ2VuZXJpYy1wYXJzZS11cmwgImh0dHA6Ly93d3cuZ251Lm9yZy8iKSkKKyAg ICAgICAgICh1cmwtaHR0cC1kYXRhICJ0ZXN0IikpCisgICAgKHdpdGgtdGVtcC1idWZmZXIKKyAg ICAgIChpbnNlcnQgKHVybC1odHRwLWNyZWF0ZS1yZXF1ZXN0KSkKKyAgICAgIChnb3RvLWNoYXIg KHBvaW50LW1pbikpCisgICAgICAoc2hvdWxkIChsb29raW5nLWF0ICJQT1NUIC8gSFRUUC8xLjFc clxuIikpCisgICAgICAoc2hvdWxkIChzZWFyY2gtZm9yd2FyZCAiQWNjZXB0OiAqLypcclxuIikp CisgICAgICAoc2hvdWxkIChzZWFyY2gtZm9yd2FyZCAiQ29udGVudC1sZW5ndGg6IDRcclxuIikp CisgICAgICAoc2hvdWxkIChzZWFyY2gtZm9yd2FyZCAiSG9zdDogd3d3LmdudS5vcmdcclxuIikp CisgICAgICAoZ290by1jaGFyIChwb2ludC1taW4pKQorICAgICAgKHNob3VsZCAoc2VhcmNoLWZv cndhcmQgIlxyXG5cclxuIikpCisgICAgICAoc2hvdWxkIChzZWFyY2gtZm9yd2FyZCAidGVzdCIp KQorICAgICAgKHNob3VsZCAoZXF1YWwgKHBvaW50KSAocG9pbnQtbWF4KSkpKSkpCgo= --001a113675249281ec04ef14c493-- From debbugs-submit-bounces@debbugs.gnu.org Sun Jan 05 04:57:22 2014 Received: (at 16220) by debbugs.gnu.org; 5 Jan 2014 09:57:22 +0000 Received: from localhost ([127.0.0.1]:35224 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VzkSQ-0002xk-1q for submit@debbugs.gnu.org; Sun, 05 Jan 2014 04:57:22 -0500 Received: from hermes.netfonds.no ([80.91.224.195]:34383) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VzkSO-0002xa-6R for 16220@debbugs.gnu.org; Sun, 05 Jan 2014 04:57:20 -0500 Received: from cm-84.215.51.58.getinternet.no ([84.215.51.58] helo=stories.gnus.org) by hermes.netfonds.no with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1VzkSA-0002bb-1p; Sun, 05 Jan 2014 10:57:06 +0100 From: Lars Magne Ingebrigtsen To: Stefan Monnier Subject: Re: bug#16220: url-http.el: Not conforming to HTTP spec References: Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAALVBMVEVpXUkaEhWLOTj9/vpA Jybi5MuOdGh5VDyGa1zy+eN/SD3+//6WfW23kHb6/fLIQ5VxAAAB/0lEQVQ4jXWUv2vbQBTHn0GE DKVEoCGz6erpcBaDkMprSCHdqsGkCZ2EBu+BTh6CetB0ahcP9dAxq8n0ILgQskRZDIZ6uEl0CKX6 G/qeJMvyD32Qzfn70Xuns+8MsY601hDpfV2xF4YhxLHWcdSy0EE8QQ8t5sCz9iAOdRzHLd+xfefQ t22+HLT9XEiF7fDnQ7TtluP7iFLBPSN9ZYHnwTGA10LgMYtGkNnMLMl25LkCr7lZAzcl/HAD8/Rk Hnjw+fLTJbQLzAYzEZ1ZZ7YpDLRn7c5WKmI1DObzIDDmvBRBSX9UJwignmbMKHteiSrNlJJ3Vrko 01SlPSW4YkDycX6vUhc9oruAJq6Ifnk/592AiG7PiSaVSP/8/tajQsxZZIUYZ+rfQnHInTjly81G IAXKtU7yUOjzS2XPLMap6r6YnhEZsyA6wjMpWYqvHx7pDvEN0Xt8mZeATM3iRyWctzKRCzx1qlRi uEEQXBB9f/elEkpRd7Gc+9b8FaGAV6eqJ6pgMd4pSEH+bWyLiVSku3pB/jPJg63nLtz85H1SbKw4 HCSJSZgw0st9xbxq16mJchdti3UAXzcIew1EPoAoB3RDrGgW4S7kvyJ5KMa8tmQKQ9gfDq9ljcDL rMS9z4ffx1O8+ni9IeRw46n3C1gs+w4GydTyRBx798OaCMOkzn+MvPe5+6wfNAAAAABJRU5ErkJg gg== X-Now-Playing: Barbara Morgenstern's _Vermona ET 6-1_: "Der Wunsch Teil Zwei" X-Hashcash: 1:23:140105:16220@debbugs.gnu.org::3wkYtCcpJ1g52QJP:00000000000000000000000000000000000000000E8l X-Hashcash: 1:23:140105:sztywny@gmail.com::+RmgN04FxDYIA6kB:000000000000000000000000000000000000000000001Pe0 X-Hashcash: 1:23:140105:monnier@iro.umontreal.ca::6L/7CfY+DVP5jWFZ:0000000000000000000000000000000000000vF+K Date: Sun, 05 Jan 2014 10:57:05 +0100 In-Reply-To: (Stefan Monnier's message of "Wed, 01 Jan 2014 21:21:04 -0500") Message-ID: User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-MailScanner-ID: 1VzkSA-0002bb-1p X-Netfonds-MailScanner: Found to be clean X-Netfonds-MailScanner-From: larsi@gnus.org MailScanner-NULL-Check: 1389520626.5898@FgUpOWRsPf8O2I1FClhQPw X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 16220 Cc: =?utf-8?Q?Jaros=C5=82aw_Rzesz=C3=B3tko?= , 16220@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) Stefan Monnier writes: > Probably partly historical evolution (there was no place to add new > "parameters", so adding dynamic vars was an easy way to add more control > without breaking existing code). Yes. This summer, I started rewriting url-retrieve and friends in the way that was discussed on emacs-devel a ... couple years back: (with-url "http://fsf.org" :timeout 10 :concurrency 5 :request-method "POST" :headers '(("Foo" . "Bar")) (message "The result was: %s" (buffer-string))) but I kinda stopped before I really got started, because I couldn't figure out how to make this work in the non-lexical binding case. And having this work only with lexical binding seemed kinda meh. You wouldn't happen to have any ideas in that area? >"? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Sun Jan 05 08:25:22 2014 Received: (at 16220) by debbugs.gnu.org; 5 Jan 2014 13:25:22 +0000 Received: from localhost ([127.0.0.1]:35525 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Vznhd-0004U1-Vq for submit@debbugs.gnu.org; Sun, 05 Jan 2014 08:25:21 -0500 Received: from mail-pb0-f44.google.com ([209.85.160.44]:53181) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VznhW-0004Tk-9c for 16220@debbugs.gnu.org; Sun, 05 Jan 2014 08:25:15 -0500 Received: by mail-pb0-f44.google.com with SMTP id rq2so17398153pbb.17 for <16220@debbugs.gnu.org>; Sun, 05 Jan 2014 05:25:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=K3VMP3suDQTFhSO7y7PB1HeUeAW9goGIY7Z/sh+e3is=; b=gtRKbG7iuIsB1pNpYjqlUD+H+WM5hyGzQAk6zs5pkfa/bNc0E1DOISl22xcOzBZJv2 Y5dxgNl23QXXYgo7wTscwIdzn1SDQQPQvl7GEZSkdkZrrgYpCy/kQwz8oAV0BaHcn+H5 Vuua3apZgogWteelKk2FTF4IHoqdX0axhBEbWbT8pIDSB7oas/dkiOKctcg0sp5uhaRg Yuo8GlbLB2JsHnu1bzfZ9fc3Pygprruyrf6/Y09BpNq3EEIpX85SZAcxpDcual98Gb61 Q7Zf+lbQka1NH2bM/EaajM3QB2MlkvWq9fZt+hAymSyHyzue7zcn32tJcPobkhWwtORb raAA== MIME-Version: 1.0 X-Received: by 10.68.226.70 with SMTP id rq6mr99866192pbc.107.1388928309464; Sun, 05 Jan 2014 05:25:09 -0800 (PST) Received: by 10.66.101.201 with HTTP; Sun, 5 Jan 2014 05:25:09 -0800 (PST) In-Reply-To: References: Date: Sun, 5 Jan 2014 14:25:09 +0100 Message-ID: Subject: Re: bug#16220: url-http.el: Not conforming to HTTP spec From: =?ISO-8859-2?Q?Jaros=B3aw_Rzesz=F3tko?= To: Lars Magne Ingebrigtsen Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 16220 Cc: 16220@debbugs.gnu.org, Stefan Monnier X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Hi, 2014/1/5 Lars Magne Ingebrigtsen : > This summer, I started rewriting url-retrieve and friends in the way > that was discussed on emacs-devel a ... couple years back: > > (with-url "http://fsf.org" :timeout 10 > :concurrency 5 > :request-method "POST" > :headers '(("Foo" . "Bar")) > (message "The result was: %s" (buffer-string))) > > but I kinda stopped before I really got started, because I couldn't > figure out how to make this work in the non-lexical binding case. And > having this work only with lexical binding seemed kinda meh. > > You wouldn't happen to have any ideas in that area? >"? I think a natural way of representing the request if this was to be designed today would be to use alists all the way, perhaps with optional arguments for adjusting how precisely the request itself should be sent and handled: (http "http://www.fsf.org/xyz/zyx" '((method . "GET") (path . "/") (headers . (("Accept-Encoding" . "UTF-8"))) (form . (("param1" . "value1")))) :timeout 10) This breaks compatibility of course though, as do any sensible changes I can think of. So meanwhile I would be happy if the patch got accepted, it would at least make the library at all usable to me, even if not the easiest to use. Cheers, Jaros=B3aw Rzesz=F3tko From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 06 10:06:55 2014 Received: (at 16220) by debbugs.gnu.org; 6 Jan 2014 15:06:56 +0000 Received: from localhost ([127.0.0.1]:38648 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W0BlX-0007sH-1C for submit@debbugs.gnu.org; Mon, 06 Jan 2014 10:06:55 -0500 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:17709) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W0BlT-0007s5-FJ for 16220@debbugs.gnu.org; Mon, 06 Jan 2014 10:06:52 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABK/CFFFxKG9/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLNBIUGA0kiB4GwS2RCgOIYZwZgV6DFQ X-IPAS-Result: Av4EABK/CFFFxKG9/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLNBIUGA0kiB4GwS2RCgOIYZwZgV6DFQ X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="44220101" Received: from 69-196-161-189.dsl.teksavvy.com (HELO pastel.home) ([69.196.161.189]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 06 Jan 2014 10:06:50 -0500 Received: by pastel.home (Postfix, from userid 20848) id 81AE162F04; Mon, 6 Jan 2014 10:06:50 -0500 (EST) From: Stefan Monnier To: Lars Magne Ingebrigtsen Subject: Re: bug#16220: url-http.el: Not conforming to HTTP spec Message-ID: References: Date: Mon, 06 Jan 2014 10:06:50 -0500 In-Reply-To: (Lars Magne Ingebrigtsen's message of "Sun, 05 Jan 2014 10:57:05 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 16220 Cc: =?utf-8?Q?Jaros=C5=82aw_Rzesz=C3=B3tko?= , 16220@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) > but I kinda stopped before I really got started, because I couldn't > figure out how to make this work in the non-lexical binding case. And > having this work only with lexical binding seemed kinda meh. I think it's perfectly OK to have it require lexical-binding. The macro can signal an error if lexical-binding is nil. Stefan From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 07 14:30:33 2014 Received: (at 16220) by debbugs.gnu.org; 7 Jan 2014 19:30:33 +0000 Received: from localhost ([127.0.0.1]:41481 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W0cMC-0000Ay-Jw for submit@debbugs.gnu.org; Tue, 07 Jan 2014 14:30:33 -0500 Received: from mail-pb0-f52.google.com ([209.85.160.52]:34781) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W0cM9-0000An-62 for 16220@debbugs.gnu.org; Tue, 07 Jan 2014 14:30:29 -0500 Received: by mail-pb0-f52.google.com with SMTP id uo5so533549pbc.39 for <16220@debbugs.gnu.org>; Tue, 07 Jan 2014 11:30:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=FfzIei/PaJ8/G+r3vWTdGCirviBp3hflOfX0pzK3ARg=; b=Aw8zBpGSMPz/VYFDflk6+ncm4bSzvqTwboWXIQFxveCz6md1yTYho/MH9UOPeDz2p7 rUsriSm2LwqojyJd9401FFRauDKe+h374DMLXlkCVJwDwE8qmDnZr7DIjH1LkPKSnX2s rg3DLMBvZt8jhM+/SL69AdnGO4XhuhcHekF0ojyInQ3HqVwJVKi5qr9yzcRw93TZwI0H dUGD+eVtJTo+BEu1LUHYadcmtEkfOp6PKudcqobwxqM1ephqWrkDWqGJ+FVKPSDOKNHC E/EPBUO/WDOkWyvdi8zQ8I444KwF0CZ64bFo9VAlzvYnD/5ly6YlkYKiEP0z6rlfYfdB FPkQ== MIME-Version: 1.0 X-Received: by 10.66.155.7 with SMTP id vs7mr7439718pab.42.1389123027032; Tue, 07 Jan 2014 11:30:27 -0800 (PST) Received: by 10.66.101.201 with HTTP; Tue, 7 Jan 2014 11:30:26 -0800 (PST) In-Reply-To: References: Date: Tue, 7 Jan 2014 20:30:26 +0100 Message-ID: Subject: Re: bug#16220: url-http.el: Not conforming to HTTP spec From: =?ISO-8859-2?Q?Jaros=B3aw_Rzesz=F3tko?= To: Stefan Monnier Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 16220 Cc: 16220@debbugs.gnu.org, Lars Magne Ingebrigtsen X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Hi, Is there any chance my patch gets committed or at least that the extra "\r\n" finally gets removed? Cheers, Jaros=B3aw Rzesz=F3tko 2014/1/6 Stefan Monnier : >> but I kinda stopped before I really got started, because I couldn't >> figure out how to make this work in the non-lexical binding case. And >> having this work only with lexical binding seemed kinda meh. > > I think it's perfectly OK to have it require lexical-binding. > The macro can signal an error if lexical-binding is nil. > > > Stefan From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 08 13:30:09 2014 Received: (at 16220) by debbugs.gnu.org; 8 Jan 2014 18:30:09 +0000 Received: from localhost ([127.0.0.1]:43037 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W0xtI-0003wL-EX for submit@debbugs.gnu.org; Wed, 08 Jan 2014 13:30:08 -0500 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:18116) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W0xtE-0003vU-MO for 16220@debbugs.gnu.org; Wed, 08 Jan 2014 13:30:05 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFABK/CFFFxKG9/2dsb2JhbABEhke4Rxdzgh4BAQQBIzMjBQsLGgIYDgICFA0LDSQTh38DCQauX4hsDYlVgSOKb4NlgRMDiGGLVo0PgzSBXoMV X-IPAS-Result: AgAFABK/CFFFxKG9/2dsb2JhbABEhke4Rxdzgh4BAQQBIzMjBQsLGgIYDgICFA0LDSQTh38DCQauX4hsDYlVgSOKb4NlgRMDiGGLVo0PgzSBXoMV X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="44495498" Received: from 69-196-161-189.dsl.teksavvy.com (HELO pastel.home) ([69.196.161.189]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 08 Jan 2014 13:30:02 -0500 Received: by pastel.home (Postfix, from userid 20848) id 139A360F94; Wed, 8 Jan 2014 13:29:55 -0500 (EST) From: Stefan Monnier To: =?utf-8?Q?Jaros=C5=82aw_Rzesz=C3=B3tko?= Subject: Re: bug#16220: url-http.el: Not conforming to HTTP spec Message-ID: References: Date: Wed, 08 Jan 2014 13:29:54 -0500 In-Reply-To: (=?utf-8?Q?=22Jaros=C5=82aw_Rzesz=C3=B3tko=22's?= message of "Tue, 7 Jan 2014 20:30:26 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 16220 Cc: 16220@debbugs.gnu.org, Lars Magne Ingebrigtsen X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) > Is there any chance my patch gets committed or at least that the extra > "\r\n" finally gets removed? I installed the patch below. Thank you very much, Stefan =3D=3D=3D modified file 'lisp/url/ChangeLog' --- lisp/url/ChangeLog 2014-01-01 07:43:34 +0000 +++ lisp/url/ChangeLog 2014-01-08 18:05:12 +0000 @@ -1,3 +1,8 @@ +2014-01-08 Jaros=C5=82aw Rzesz=C3=B3tko + + * url-http.el (url-http-create-request): Don't add extra \r\n after + http data (bug#16220). + 2013-12-28 Glenn Morris =20 * url-history.el (url-history-track): =3D=3D=3D modified file 'lisp/url/url-http.el' --- lisp/url/url-http.el 2014-01-01 07:43:34 +0000 +++ lisp/url/url-http.el 2014-01-08 18:03:55 +0000 @@ -356,9 +356,7 @@ ;; End request "\r\n" ;; Any data - url-http-data - ;; If `url-http-data' is nil, avoid two CRLFs (Bug#8931). - (if url-http-data "\r\n"))) + url-http-data)) "")) (url-http-debug "Request is: \n%s" request) request)) From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 18 17:35:41 2014 Received: (at 16220-done) by debbugs.gnu.org; 18 Jan 2014 22:35:42 +0000 Received: from localhost ([127.0.0.1]:56435 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W4eUP-0005sa-HN for submit@debbugs.gnu.org; Sat, 18 Jan 2014 17:35:41 -0500 Received: from smtp.cs.ucla.edu ([131.179.128.62]:48695) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W4eUK-0005sN-Ln for 16220-done@debbugs.gnu.org; Sat, 18 Jan 2014 17:35:37 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 7872639E8015 for <16220-done@debbugs.gnu.org>; Sat, 18 Jan 2014 14:35:35 -0800 (PST) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pBe1k+MH+LGz for <16220-done@debbugs.gnu.org>; Sat, 18 Jan 2014 14:35:35 -0800 (PST) Received: from [192.168.1.9] (pool-108-0-233-62.lsanca.fios.verizon.net [108.0.233.62]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 268A839E8011 for <16220-done@debbugs.gnu.org>; Sat, 18 Jan 2014 14:35:35 -0800 (PST) Message-ID: <52DB01B6.1000705@cs.ucla.edu> Date: Sat, 18 Jan 2014 14:35:34 -0800 From: Paul Eggert Organization: UCLA Computer Science Department User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: 16220-done@debbugs.gnu.org Subject: Re: url-http.el: Not conforming to HTTP spec Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.7 (--) X-Debbugs-Envelope-To: 16220-done X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.7 (--) Marking the bug as done since Stefan installed a patch. From unknown Mon Jun 16 23:39:38 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sun, 16 Feb 2014 12:24:03 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator