Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
You know HTTP?
Well, a group of developers got together to destroy it citing improving it as their cover story.
And if you're wondering, the changes they're proposing will bust things we actively use at TASVideos, and are also used frequently at other sites too, probably way more than we use them.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
I get how this is stupid, but is this actually happening or just a proposal? And how likely are clients to actually change their behaviors based on a broken spec? It sounds more like the spec is being adjusted so that certain (rarely-used?) clients can claim they follow spec.
I mean, if your broken client can't use TASVideos, isn't that your problem?
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
And those changes are in HTTPbis specs, not HTTP2 specs.
And the first are already being copyedited for publication and there will not be substantive changes.
HTTP2 has some even worse braindamage (but the spec isn't even in last call).
The absolute worst is specifying 100-Continue handling when proxying to HTTP/1.1 not only in a way that is absolutely forbidden by HTTP/1.1, but is about the way that does the most damage.
There are other handlings that would still violate HTTP/1.1 but do far less damage (because those clients already have to handle the unreliability of 100-Continue).
Basically, it would render 100-Continue even on HTTP/1.1 absolutely unsafe to use.
Could someone explain to the initiated what it means for a POST request to be changed to a GET request on HTTP redirection, why it's a good/bad thing, and how this change will completely destroy the WWW?
Could someone explain to the initiated what it means for a POST request to be changed to a GET request on HTTP redirection?
Basically, POST is form submission, and GET is fetch page. So the form data is lost (if the server didn't act on it already, and if it did, it should use 303 code).
Could someone explain to the initiated what it means
Not hard to explain to the initiated. More like we need an explanation for the uninitiated, which most of us are.
Anyway, I don't get this topic and I don't see why I should care about this issue.
Could someone explain to the initiated what it means for a POST request to be changed to a GET request on HTTP redirection?
Basically, POST is form submission, and GET is fetch page. So the form data is lost (if the server didn't act on it already, and if it did, it should use 303 code).
Ok, I suppose it's good to explain what POST and GET themselves mean, but it was not what I was asking. (I know what they mean.) I expressed myself poorly.
If a program (such as a browser) makes a POST request to a server, and the server returns a redirection response to another URL, why would the program make a new request to that other URL as a GET instead of the original POST? What sense does that make? (Or is it, perhaps, something else along the line that's changing the POST to a GET?) What is the purpose of the change? Why do we need to types of redirection responses, one to make the change and another to not make it? And, more importantly, why does changing the meaning of the response code break the WWW?
FractalFusion wrote:
Not hard to explain to the initiated. More like we need an explanation for the uninitiated, which most of us are.
If a program (such as a browser) makes a POST request to a server, and the server returns a redirection response to another URL, why would the program make a new request to that other URL as a GET instead of the original POST? What sense does that make?
If the server really processed the POST and is redirecting to results, then changing to GET makes sense.
If the server didn't process it yet, then it needs to be resent as POST. These kinds of redirects are done for backward compatiblity and in some APIs.
The problem with method changing with 301 is that it is permanent (which means cacheable) redirect. So if the client caches it and changes method, using POST with that URL just broke...
Some background:
The redirects are classified by:
- Is the redirect permanent (cacheable) or temporary (not cacheable).
- Does the redirect change method or not (or either depending on client!)?
301:
As originally specified: Permanent, do not change method.
RFC2616: Permanent, don't change method (note: Some buggy implementations)
HTTPbis: Permement, either change or don't change method.
302:
As originally specified: Temporary, do not change method.
RFC2616: Temporary, don't change method (note: lots of buggy implementations).
HTTPbis: Temporary, either change or don't change method.
303:
As originally specified: Temporary, change method.
RFC2616: Temporary, change method.
HTTPbis: Temporary, change method.
307:
As originally specified: Temporary, don't change method.
RFC2616: Temporary, don't change method.
HTTPbis: Temporary, don't change method.
308:
As originally specified: Permanent, don't change method (the same as 301!).
RFC2616: N/A
HTTPbis: Permanent, don't change method.
So the idea is that a program can make a POST request, and then the server can tell it "ok, I got it, now go to this other URL for the results" (which it should retrieve with a GET method)?
(Although one could think that why the original POST request couldn't have returned the results directly...)
So the idea is that a program can make a POST request, and then the server can tell it "ok, I got it, now go to this other URL for the results" (which it should retrieve with a GET method)?
That's the idea of 303.
As to why, consider if the response would just be identical to that page. If the answer was sent directly, then browsers would record that page as being received from POST, which breaks e.g. page refresh.
As to why, consider if the response would just be identical to that page. If the answer was sent directly, then browsers would record that page as being received from POST, which breaks e.g. page refresh.
Does, for example, tasvideos.org/forum use this technique?
Joined: 10/6/2011
Posts: 1697
Location: RU · ID · AM
Warp wrote:
Ilari wrote:
As to why, consider if the response would just be identical to that page. If the answer was sent directly, then browsers would record that page as being received from POST, which breaks e.g. page refresh.
Does, for example, tasvideos.org/forum use this technique?
Write a post. Press «submit». You’ll see a redirection page, which was sent in reply to your POST request. This is clearly visible when you try pressing F5 on that redirection page — your browser will suggest repeating the request. So, TASvideos forum isn’t using HTTP redirection, but HTML or JavaScript redirection instead.
Such behavior may often result in double posts in many web applications. Imagine that the server proccessed your request, but your browser failed to get the reply. You’ll probably press F5, and the request will be processed again. Another way to do it is pressing submit button multiple times, for example, when you are too impatient or the server (or network connection) is too slow.
One of the methods to prevent repeative POST requests is using some secret key, which is generated whenever a form is created, and saved into the session and into a hidden field within the form. When you submit that form, the server side script validates your request by checking the secret code, and deletes it from the session. It also helps protecting from some kind of attacks, known as CSRF.
S3&A [Amy amy%] improvement (with Evil_3D & kaan55) — currently in SPZ2
my TAS channel · If I ever come into your dream, I’ll be riding an eggship :)
As to why, consider if the response would just be identical to that page. If the answer was sent directly, then browsers would record that page as being received from POST, which breaks e.g. page refresh.
Does, for example, tasvideos.org/forum use this technique?
I thought more about some pages on the wiki side (especially if modules taking POSTs are involved).
