|
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 &
(Morningstar Partners Ltd d.b.a.)
Aurora Jet Partners Ph: 780-453-3022 x 1122 |