Re: Last Call: <draft-ietf-httpbis-http2-16.txt> (Hypertext Transfer Protocol version 2) to Proposed Standard

Chris Dailey <chris@maei.ca> Fri, 09 January 2015 14:57 UTC

Return-Path: <chris@maei.ca>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 398541A8AA8 for <ietf@ietfa.amsl.com>; Fri, 9 Jan 2015 06:57:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6nCKiYbGufXY for <ietf@ietfa.amsl.com>; Fri, 9 Jan 2015 06:57:01 -0800 (PST)
Received: from yeggate.maei.ca (YEGGate.MAEI.CA [209.82.26.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF0321A00E7 for <ietf@ietf.org>; Fri, 9 Jan 2015 06:57:01 -0800 (PST)
Received: from outlook.maei.ca ([192.168.60.21]) by yeggate.maei.ca (8.14.4/8.14.4) with ESMTP id t09Ev0mM024925 for <ietf@ietf.org>; Fri, 9 Jan 2015 07:57:00 -0700
Received: from YEG-EXMB01.MGC.LOCAL ([fe80::f93e:c703:bee5:ed2c]) by YEG-EXCH02.MGC.LOCAL ([fe80::4170:e8f1:a882:dbbf%11]) with mapi id 14.02.0387.000; Fri, 9 Jan 2015 07:56:59 -0700
From: Chris Dailey <chris@maei.ca>
To: "ietf@ietf.org" <ietf@ietf.org>
Subject: Re: Last Call: <draft-ietf-httpbis-http2-16.txt> (Hypertext Transfer Protocol version 2) to Proposed Standard
Thread-Topic: Re: Last Call: <draft-ietf-httpbis-http2-16.txt> (Hypertext Transfer Protocol version 2) to Proposed Standard
Thread-Index: AdAsF35ZBFSXk77CST2lTwCKcyBv1A==
Date: Fri, 9 Jan 2015 14:56:59 +0000
Message-ID: <DAC243A5BA88CB4CBE0C9C9B2C3D32FD305F1C@YEG-EXMB01.MGC.LOCAL>
Accept-Language: en-US, en-CA
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [192.168.60.168]
Content-Type: multipart/alternative; boundary="_000_DAC243A5BA88CB4CBE0C9C9B2C3D32FD305F1CYEGEXMB01MGCLOCAL_"
MIME-Version: 1.0
X-CanIt-Geo: No geolocation information available for 192.168.60.21
X-CanItPRO-Stream: base:default
X-Canit-Stats-ID: Bayes signature not available
Received-SPF: none (yeggate.maei.ca: domain of chris@maei.ca does not designate permitted sender hosts) receiver=yeggate.maei.ca; client-ip=192.168.60.21; envelope-from=<chris@maei.ca>; helo=outlook.maei.ca; identity=mailfrom
X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.168.60.1
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/CdRqH7_o3qtqyXq4Z3NNmT3BSVE>
X-Mailman-Approved-At: Fri, 09 Jan 2015 08:39:23 -0800
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Jan 2015 15:07:24 -0000

Greetings,

One thing I would like to see in HTTP/2 is a more efficient way of doing the extremely common PRG (Post-Redirect-Get) pattern, which is 2 separate requests (1. Post/Redirect 2. Get/Content).

When the redirect is to the same server, there should not need to be a redirect to perform the second request; the first response should just send the content instead of telling the client to redirect to get the content, and also tell the browser what the new URI is (local to the existing server).

Protocol-wise, I think this might be achievable by a new HTTP code; this is not an exact proposal, but to give you an example, I'll choose "207 - Redirected Content" for a new HTTP code.  It would require a Location field in the response to indicate the new page URI.  I'm probably missing out on lots of details, but that's the general idea.

On the server side, this would mean that a single HTTP request can result in two page lifecycles being processed, with the benefit of only one request occurring instead of two.  If a client requests using HTTP/1.1, then the server should be smart enough to send the redirect to be compliant with HTTP/1.1.

>From the end user's perspective, their browser would treat this just as they currently treat a redirect.  When the user requests a reload on the new page, the browser should perform a GET, not try to re-POST the page.

Regards,
Chris

Chris Dailey
Software Developer for the Morningstar Group of Companies
Morningstar Air Express Inc<http://www.maei.ca/> & (Morningstar Partners Ltd d.b.a.) Aurora Jet Partners<http://www.aurorajet.ca/>
Ph: 780-453-3022 x 1122