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: Tue, 2 Feb 2016 00:08:00 +0600 Message-ID: References: <87oac0o64s.fsf@petton.fr> <87egcwnx88.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 1454350112 13687 80.91.229.3 (1 Feb 2016 18:08:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 1 Feb 2016 18:08:32 +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 19:08:30 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 1aQItp-00027V-Ib for ged-emacs-devel@m.gmane.org; Mon, 01 Feb 2016 19:08:29 +0100 Original-Received: from localhost ([::1]:53626 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aQIto-0007N5-Ov for ged-emacs-devel@m.gmane.org; Mon, 01 Feb 2016 13:08:28 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38208) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aQIth-0007Mo-RG for emacs-devel@gnu.org; Mon, 01 Feb 2016 13:08:25 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aQItg-0005cg-VP for emacs-devel@gnu.org; Mon, 01 Feb 2016 13:08:21 -0500 Original-Received: from mail-lf0-x235.google.com ([2a00:1450:4010:c07::235]:36719) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aQItg-0005ca-NH for emacs-devel@gnu.org; Mon, 01 Feb 2016 13:08:20 -0500 Original-Received: by mail-lf0-x235.google.com with SMTP id 78so53445152lfy.3 for ; Mon, 01 Feb 2016 10:08:20 -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=BfjFkoR4hDCcJ7u/bDmf/F7BB6qEhqTGLOk79FrINAA=; b=Z6CW0oVOy/QWizy650AKhciuVcZIeTzY+fZu8fsous/+18svV4fSkjdJpkPCosyKd4 VVIlQUX4HQMlZNJ1n2Z9mLFx/bI11hGXTLdCZQy1ObAZVooq1UTE6rli6RE0k6vrKn7y D6yOsvXxOPGuqsF4PoEZvAw0auutwf2mQg4lwayTCsLp3wFlgR6puQXjCzdizHwFEFWS W+fSBoXfvCvgwG1tZlRm/WB7kA8iuxWfSbYwcyq7E6ShzT59kNsjJupEWMoBJYLm/Evc xJKVVUY91JXZGHhUJWrtH84DQIlMfcbx+i9RerVKz19QLLPAcY2yvAhzlKIxUGbAqsXl s28g== 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=BfjFkoR4hDCcJ7u/bDmf/F7BB6qEhqTGLOk79FrINAA=; b=Kr7ldyPbmJ8BRALgykaUYNPVf0M2yy9o7nSVwfr8/nplGDYw1YiUMc6El1p9l6jYsw pkvWVa9jggfzbYNGY7TAxsar7kmbMI5y2kD6/y+YFFBTnQ465FovoZ6QpBawKKHvzYZ9 UD3zFULO5B1UuWe+PEbjdP8p/hAqBZ2iEOD2nxOgdwT79dDQ+MgEfy8bmjDVJJ1lIL5U Pc5+p0SUx9n7209EFMpHzYWncQFNRaa79+MLFYYJTxreIj3o3JpDhCbfFAhhl9m7dTNM 1e0e34+FusLFTt1NwmjpmvcIiKYfbhyOiXSk1ClTk2IbV34qpzyKonX+/mN/VZT+kxOh KGyQ== X-Gm-Message-State: AG10YOQuD7pkUxs9wwyW6Jjm3lE22Eqcp3zt1aDzPD20G1XO4vRdMOQiAiqlY894Zp5IwwaHugorZdrItOKUDQ== X-Received: by 10.25.29.147 with SMTP id d141mr7758542lfd.26.1454350099826; Mon, 01 Feb 2016 10:08:19 -0800 (PST) Original-Received: by 10.112.7.100 with HTTP; Mon, 1 Feb 2016 10:08:00 -0800 (PST) In-Reply-To: <87egcwnx88.fsf@petton.fr> X-Google-Sender-Auth: Y0attP77o6jtfqRQJ_KLn99c6lw X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a00:1450:4010:c07::235 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:199132 Archived-At: On Mon, Feb 1, 2016 at 11:42 PM, Nicolas Petton wrote: > What should we do then? The current implementation seems to just > ignores the redirection, I would at least ask the user for a > confirmation. That=E2=80=99s the million dollar question, of course :) Well-behaved contemporary sites should probably not respond with 301 and 302 to POST requests, preferring 303 for =E2=80=9CI have processed your request, now please navigate to this new page=E2=80=9D and 307 for =E2=80= =9CI have not processed your request but the handler on that other URI might=E2=80=9D. Older sites probably expect 301s and 302s to be handled by the client in the fashion that is correct for 303. Sites that use 301 and 302 redirects as intended expect them to be handled like 307. If I were designing an HTTP client library now, I would handle 301 and 302 the same way as 307 by default: no confirmation, no method change, send the same request data. But I would provide an escape hatch =E2=80=94 a single flag that, when explicitly specified, forbids following redirects and just returns the 30x codes to the application which should then decide what to do. I would cite RFC 7231 to everybody who complained about my choice of defaults ;) cURL does not follow redirects by default. When directed to with the -L/--location switch, it defaults to changing the method to GET for 301, 302 and 303 but keeping the original method for 307. It has further switches --post301, --post302 and the bizarre --post303 to keep POST method for these respective redirects. Its manual says the default behavior is non-compliant. Wget, on the other hand, keeps the original method on 301, 302 and 307, and the manual says it is with accordance to RFC 2616.