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