Re: lynx-dev Post, Get prompt... plus bad html errors

[Frederic Briere]

> > Could someone please explain to me why the 
> > Redirection of POST content. P)roceed, see U)RL, use G)ET or C)ancel
> > prompt comes up?
> 
> I believe that the basic issue is one of privacy or information
> security.  When you submitted a form with method POST, you agreed

That's part of it. HTTP protocol requires that the user confirm any
redirection that is neither GET nor HEAD. Obviously, POST falls into
this category.

The reason why G)ET is almost always the right choice, and P)roceed
never works, is because of CGIs (and browsers, of course) breaking the
protocol. Following a 302 (Moved Temporarily), the HTTP client should
issue another request to the URI specified in Location:. The type of
this request (GET, HEAD, POST...) should not be altered.

Now, many programmers don't appreciate the subtle difference between GET
and POST redirection when it comes to CGI. (I don't blame them -- I
can't remember seeing this issue raised anywhere.) Under GET, all
information fed through CGI is within the URI, and thus vanishes upon
redirection. Under POST though, the information is to be fed within the
request, no matter what the URI is.

Unfortunately, NN and IE seem to translate a redirected POST to GET,
thus both breaking the protocol, and inciting other people to do so.
(How typical...)

(That's too bad, since it defeats the whole idea of 30x. One could, for
example, have a central front-end CGI that would randomly redirect a
request to one of many mirrors.)

Therefore, Lynx allows you to take a look at the U)RL, and judge for
yourself. If it seems to be a CGI, then the resource really *has* moved,
and you should P)roceed to POST the same information to it. Otherwise,
you're probably directed to a static document, which you should G)ET.


Just in case I missed something, here's the relevant part of RFC2068:


10.3.3 302 Moved Temporarily

   The requested resource resides temporarily under a different URI.
   Since the redirection may be altered on occasion, the client SHOULD
   continue to use the Request-URI for future requests. This response is
   only cachable if indicated by a Cache-Control or Expires header
   field.

   If the new URI is a location, its URL SHOULD be given by the Location
   field in the response. Unless the request method was HEAD, the entity
   of the response SHOULD contain a short hypertext note with a
   hyperlink to the new URI(s).

   If the 302 status code is received in response to a request other
   than GET or HEAD, the user agent MUST NOT automatically redirect the
   request unless it can be confirmed by the user, since this might
   change the conditions under which the request was issued.

     Note: When automatically redirecting a POST request after receiving
     a 302 status code, some existing HTTP/1.0 user agents will
     erroneously change it into a GET request.


-- 
         Frederic Briere        <*>        <address@hidden>
     [hyrule.ddns.org]    March 1st is I-Love-My-Stable-Machine Day!
 $_=reverse q=ebannaw rekcah lrep a tsuJ=;s=a=another=;print qq=$_.\n=;