Subject: Re: Complex CGI question (possibly javascript) Wed Mar 31 17:20:50 1999 > I don't know why, but it seems lately most of my posts get >misunderstood :-(. Yes, doing a Location: redirect with a GET query >string is fairly easy, but what I need is a redirect such that the >browser POSTs to the second server. in that case, the short answer is: "you can't". if you explicitly need a second POST query from the browser, you're out of luck. it can't be done without a second click from the user's mouse. AFAIK, even Java and Javascript won't help you, because to do so would leave an opening for all sorts of security problems. the browser and server communicate using HTTP, and HTTP inherits a lot of its structure from MIME. to get a second POST from the browser, you'd have to violate the encapsulation of the MIME entities which make up an HTTP transaction, and browsers just don't do that. MIME entities come in two basic flavors: single-line, and multiline. the bulk of any HTTP message between a browser and a server will be a sequence of single-line entities. the messages which originate from the server only allow a single multi-line entity, in fact. the general structure of an HTTP server message is: Server-type: whatever \ Date: whenever | single-line entities Estamp: transaction ID string / Content-type: text/html \ | SGML declaration | multiline entity HTML document / where the structure of a generic single-line MIME entity is: name: value and the complete structure of a multiline MIME entity is: Content-type: MIME type declaration additional parameters DATA sentinel HTTP normally limits a message to a single multiline entity, so it cuts some corners to reduce overhead. both the field for additional parameters and the sentinel (which is just a string that lets the receiver know the data is done) are eliminated. the field for additional parameters is where you'd normally put the name of the information to follow, but since there's only one multiline field, giving it a name would be a waste of time. likewise, the webpage itself has a structure which lets you know when it's finished, so adding another "yes, it's really done" string would be redundant. the structure of a browser request is more or less the same as a server message, but it's prefixed with a single line that lists the request method, the name of the file to be processed, and the specific version of HTTP which will be used: GET http://www.foo.com/index.html HTTP/1.0 for instance. the GET method only supports the addition of single-line MIME entities, so the general structure of a GET request is like so: GET http://www.foo.com/index.html HTTP/1.0 User-agent: browser ID string Date: whenever HTTP-referrer: last page visited in the case of a GET request with additional information tacked on as a script parameter: click the request would look like so: GET http://www.foo.com/script.pl HTTP/1.0 User-agent: browser ID string Date: whenever Content-length: 4 Query-string: data there's a maximum limit to the length of a single-line MIME entity, because the C command which reads to the end of a line, fgets(), takes a parameter which sets an upper limit on the line length. there used to be a command which didn't take a limit, but it tended to cause buffer overruns when told to read a line that didn't have a return character at the end. that's what made the Great Internet Worm possible, and now everyone uses fgets(). usually, each application-level protocol will set its own upper limit for the acceptable length on a line. the POST method bypasses the line-length restriction by sending its data as a multiline MIME entity. the structure of a generic POST request would look like so: POST http://www.foo.com/script.pl HTTP/1.0 User-agent: browser ID string Date: whenever Content-length: 10 Content-type: text/x-encoded name=value raw HTTP doesn't support reflected POST requests, because the multiline entities used in browser and server messages overlap. what you want is a server message that looks like so: Repost-to: new URL Content-length: 10 Content-type: text/x-encoded name=value which the browser would use to assemble a new POST query. that's certainly possible in theory, but it's not part of HTTP as it curently exists. that being the case, a second POST must be explicitly constructed by the browser. again, in theory, Java and Javascript should be able to do that. unfortunately, i believe that both Javascript and the JVM place restrictions on the ability to make new network connections. the only machine you're able to make a connection to, if memory serves, is the one from which you got the current page. it's a security issue. there are countless awful things that could be done if servers are allowed to share, and possibly hijack, data among themselves. for cluelessness on that scale, you'd have to try VB or directX.. after all, they're produced by the same company who gave us Outlook (IMHO, the next version should be called "LookOut!") and by proxy, Melissa. failing the impossible and the terminally (with any luck) careless, you have three remaining options: 1. make the user click the submit button a second time 2. pass the information directly from server A to server B 3. use a redirected GET query with an extension as i understood your original question, the whole purpose of attempting a reflected POST was to avoid #1, and neither of the remaining options is really a reflected POST. #2 involves synchronization and session control issues, which means that any working solution will be fairly complex. #3 is simpler, so that's the one i mentioned. to back up a step or two, what specifically makes a reflected POST desirable/necessary in your current situation? the difference in terms of data transfer bewteen a GET and a POST is negligible as far as the script at the back end is concerned, and the input data itself is identical. what additional feature of the POST method makes the difference between: GET http://www.foo.com/script.pl HTTP/1.0 User-agent: browser ID string Date: whenever Content-length: 10 Query-string: name=value and: POST http://www.foo.com/script.pl HTTP/1.0 User-agent: browser ID string Date: whenever Content-length: 10 Content-type: text/x-encoded name=value critical?