GNU bug report logs - #701
23.0.60; url-http.el package should not rewrite POST to GET upon 301 reply

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 701 in the body.
You can then email your comments to 701 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: thomas weidner <thomas_weidner <at> gmx.de>
To: emacs-pretest-bug <at> gnu.org
Subject: 23.0.60; url-http.el package should not rewrite POST to GET upon 301 reply
Date: Tue, 12 Aug 2008 14:59:03 +0200

Hi,

when a 301 reply in url-http.el is received, requests other than GET
and HEAD are also rewritten to a GET request to the new location. This
is nearly always not what the user of the library
intended. (i.e. posting data to a url results in a GET to the new url
and the posted data is lost) The authors of url-http.el are aware of
the issue as some comments in the file show, but i think their
solution is wrong. The current behaviour is even stated as wrong in
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.2
. Some ideas whould be not to issue a new request but leave the 301 to
the user or to issue the SAME request again.

Message #10 received at 701 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: thomas weidner <thomas_weidner <at> gmx.de>
Cc: 701 <at> debbugs.gnu.org
Subject: Re: 23.0.60; url-http.el package should not rewrite POST to GET upon 301 reply
Date: Wed, 13 Aug 2008 18:33:57 -0400

> when a 301 reply in url-http.el is received, requests other than GET
> and HEAD are also rewritten to a GET request to the new location. This
> is nearly always not what the user of the library
> intended. (i.e. posting data to a url results in a GET to the new url
> and the posted data is lost) The authors of url-http.el are aware of
> the issue as some comments in the file show, but i think their
> solution is wrong. The current behaviour is even stated as wrong in
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.2
> . Some ideas whould be not to issue a new request but leave the 301 to
> the user or to issue the SAME request again.

How about the following change?  Does it work better?

*** trunk/lisp/url/url-http.el.~1.60.~	2008-07-02 07:14:37.000000000 -0400
--- trunk/lisp/url/url-http.el	2008-08-13 18:30:55.000000000 -0400
***************
*** 503,518 ****
  	    ;; automatically redirect the request unless it can be
  	    ;; confirmed by the user, since this might change the
  	    ;; conditions under which the request was issued.
! 	    (if (member url-http-method '("HEAD" "GET"))
! 		;; Automatic redirection is ok
! 		nil
! 	      ;; It is just too big of a pain in the ass to get this
! 	      ;; prompt all the time.  We will just silently lose our
! 	      ;; data and convert to a GET method.
! 	      (url-http-debug "Converting `%s' request to `GET' because of REDIRECT(%d)"
! 			      url-http-method url-http-response-status)
! 	      (setq url-http-method "GET"
! 		    url-http-data nil)))
  	   (303
  	    ;; The response to the request can be found under a different
  	    ;; URI and SHOULD be retrieved using a GET method on that
--- 503,511 ----
  	    ;; automatically redirect the request unless it can be
  	    ;; confirmed by the user, since this might change the
  	    ;; conditions under which the request was issued.
! 	    (unless (member url-http-method '("HEAD" "GET"))
! 	      (setq redirect-uri nil))
! 	    nil)
  	   (303
  	    ;; The response to the request can be found under a different
  	    ;; URI and SHOULD be retrieved using a GET method on that

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.