Redirecting POST content
Thanks to Klaus Weide for his help with this section.
When you submit a form, what you have filled in is often sent to a computer program on a remote server (a cgi-script) that tries to process your input. Normally after successful processing these programs want to show you another page. There are basically two ways to do this. The normal way is for the cgi itself to send the page back to the browser/client as its output, if this is not possible, the CGI could generate a simple page with one link on it that points to the other page. The other, and problematic, way is to send what is called a 'redirect' to the browser. This is a special type of response, with a special status code and the location of the new page. Though the latter method is more convenient for page authors, it creates some problems which are a result of the different kinds of redirects available in HTTP 1.0.
Generally these forms are sending back a code 302, which stands for 'moved temporarily'. (if the server sends back a code 301 'moved permanently', Lynx will treat this essentially the same way as a 302 code). This code was designed to be used only for documents that have really "moved temporarily" and the browser is expected to treat the new location exactly as it would the former. In this particular case it would mean redirecting the POST content (the stuff you filled in the form), that is sending it again to the new location. This is usually not what CGI authors have in mind, but they use the redirection code 302 anyway because most browsers do not follow the rules when they receive this kind of redirect (and so the authors may never learn that they are doing something wrong). The HTTP 1.0 specifications also ask that the browser confirm this action with the user before actually sending the data again, and Lynx is trying to do just that. Therefore, Lynx 2.6 will ask you:
WWW: Redirection for POST content. Proceed (y/n)?
you should reply with a No. If you let Lynx send the POST content to the new location (as it has just been asked to do), the server will usually not understand. Unfortunately, if you reply No, there is no way for you to get to the page referenced easily (short of finding the URL you were redirected to and using g)oto to go there). If you reply with a Yes, you will probably see a 501 "not implemented", or some other unexpected error may occur (like an incomplete response).
Since this incorrect use of redirection is widespread, this was a problem (in a sense punishing Lynx users for the faults of the CGI author) and it has been corrected in Lynx 2.7, which now asks:
Redirection of POST content. P)roceed, see U)RL, use G)ET, or C)ancel?
typing a G will result in Lynx requesting that the document be sent to it (i.e., it will GET the document referenced by URL). This is what most other browsers do automatically, because they do not implement the HTTP protocol correctly. If there is any doubt about this (almost no one uses redirects POST content correctly, so there generally isn't any doubt), you should type an U to see the URL. If it looks like it's a CGI (it may have 'cgi' or 'cgi-bin' in the path somewhere) use P and redirect the POST, otherwise use GET.
By now you're asking yourself why this was ever done. Can't Lynx just behave like all the other browsers and follow the 'de facto' rules? Well we wish it were so easy. The original problem is with HTTP 1.0 which failed to define a code for CGIs that would produce output that sent someone to another page (a directory service for example, that used a database of names and URLs). HTTP 1.1 corrects this, there is a new code 303 "see other" which Lynx implements. Other browsers also seem to handle this code correctly. When HTTP 1.1 is widely deployed (probably within the next few months), the problem will resolve itself as the new HTTP servers handle this situation intelligently. Meanwhile the Lynx authors have attempted to follow the specifications to the greatest extent possible, refusing to use a function for a purpose it wasn't designed to serve since in the long run this would simply exacerbate our problems.