From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Yuri Khan Newsgroups: gmane.emacs.devel Subject: Re: 307 status code handling in url-http-parse-headers Date: Mon, 1 Feb 2016 23:01:49 +0600 Message-ID: References: <87oac0o64s.fsf@petton.fr> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1454346142 6806 80.91.229.3 (1 Feb 2016 17:02:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 1 Feb 2016 17:02:22 +0000 (UTC) Cc: Stefan Monnier , Emacs developers To: Nicolas Petton Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Feb 01 18:02:22 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aQHrp-00024d-N4 for ged-emacs-devel@m.gmane.org; Mon, 01 Feb 2016 18:02:21 +0100 Original-Received: from localhost ([::1]:53422 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aQHro-0008LC-VG for ged-emacs-devel@m.gmane.org; Mon, 01 Feb 2016 12:02:20 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48007) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aQHrf-0008KQ-RV for emacs-devel@gnu.org; Mon, 01 Feb 2016 12:02:17 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aQHre-0006HG-Rx for emacs-devel@gnu.org; Mon, 01 Feb 2016 12:02:11 -0500 Original-Received: from mail-lf0-x230.google.com ([2a00:1450:4010:c07::230]:34703) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aQHre-0006GL-Gb for emacs-devel@gnu.org; Mon, 01 Feb 2016 12:02:10 -0500 Original-Received: by mail-lf0-x230.google.com with SMTP id j78so30930650lfb.1 for ; Mon, 01 Feb 2016 09:02:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=X7JsZqWD78DJ/5SVgecMNDJRG8lJaqKdTYdqoHiemAY=; b=UnELoRkC4dSx7OfKzPh/6qLelRKtZli/nT46rNF20FmJyOjYiQf2quNPJON4XzKiwp 46IL/QUSOPOjOtu1svqIPziFAH/ILMRpW98Wh7JojpFpHp3NZOKaws0nOaYlCsFTmRVB 4HO+gHr3SpZ2Mxi+ifRNc0f9eFjfR14885pAZSuYpmzl1oB9ROr+JfPdgkrujsyUt6kq JM55OYX9FWYJWp7G4uuDmXMD9ZstMRuCd8+Qgu+QneJr8wrpRRLs2yMPoXxRf7Vbe+9u EHf9V8UP7SQU9L+x6dIj4WynPNxz/ePqsevoGxlJ40gIUScVgJAnXeH1sXygzTKbx5lu I5og== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=X7JsZqWD78DJ/5SVgecMNDJRG8lJaqKdTYdqoHiemAY=; b=hpITg8jXAC5x731uAEi6ko8ybuFrSxOVtZCwR1TM3QQpZ5YGY/PGql793lP0q33qHK ZMA1fnwlE50JfqlbhoYXNkcd01bJZ17QVDt+dDQPDJF9b6w4kLTzfZyQTSGMVVo4gPSW PQbqokoQiJEl06YIphPLvkysDi8UGn0H3En2rGc5CzNGY4c4KckVEfXR3WuxLzL5dFZj +hoHul8e8IlWmSnrFrCUW5mVMCiOsgPn/xycO3WzYEBH2KZs/Gy3YRKN0fzXbgboIAI2 quiUkAnBJfLIfUOctf+rrEH+r5GiJnecAVnFarSXYAibTblbRjuGUzWpLX9L9N7vaaE2 tfZQ== X-Gm-Message-State: AG10YOSXk0nl9L5c5wHJZPJ+efADA9ONWrk5QZxMiXtJRl6Tm+2XBcNaLhrWAY9yXgs+12bnK7Z3+tttf09gPw== X-Received: by 10.25.20.165 with SMTP id 37mr6358662lfu.53.1454346129090; Mon, 01 Feb 2016 09:02:09 -0800 (PST) Original-Received: by 10.112.7.100 with HTTP; Mon, 1 Feb 2016 09:01:49 -0800 (PST) In-Reply-To: <87oac0o64s.fsf@petton.fr> X-Google-Sender-Auth: VjoOLEzVW1KtGWF3AHmTYqea_F0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a00:1450:4010:c07::230 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:199128 Archived-At: On Mon, Feb 1, 2016 at 8:30 PM, Nicolas Petton wrote: > I see that `url-http-parse-headers' won't redirect a 307 response for a > POST request. > > There's a comment about 301/302 status codes, which says that for other > requests than HEAD and GET, the user agent must not automatically > redirect, which seems to follow the RFC. > > However, should we ask the user confirmation for the redirection and do > the redirect depending on the user's choice? The sad tale of HTTP redirections :( HTTP/1.0 (RFC 1945) defined 301 and 302 requiring confirmation on redirecting methods other than HEAD and GET. The intent was that it was unknown whether the original handler performed the requested operation before responding with a redirect. The intent was also that in case of user confirmation the client would follow the redirect with the original method. Both browser implementors and web developers misunderstood the spec and used 301 and 302 redirects to mean =E2=80=9CI have performed the operat= ion you requested; follow the redirect with a GET to see results and/or further instructions=E2=80=9D. RFC 2068 recognized the above use case and introduced the 303 code to mean exactly that. It clarified that changing POST to GET on a 301 or 302 is an error. Still requires confirmation before redirecting non-idempotent methods with 301 or 302, but not for 303. HTTP/1.1 (RFC 2616) introduced the 307 code with pretty much the same wording as RFC 2068 for 302, possibly in expectation that this time developers will get it right. It required a confirmation on the 307, as well as 301 and 302. The current version of HTTP/1.1 (RFC 7231) no longer requires confirmation on 301, 302 or 307. It documents that some clients MAY (but actually should not) change POST to GET on 301 and 302. It clarifies that clients MUST NOT change the method on a 307.