Jump to content

How to avoid intermediate page "The document has moved here."


permutations

Recommended Posts

I have a CGI script written in C that processes data posted to it. It then redirects to a page known by the CGI script, but not to the form that submits to it (the CGI figures out the result location).

 

When I post to the CGI script using an HTML form, it works correctly. The problem comes when, instead of posting to the CGI, I post to an error-checking script written in PHP. When the data has been validated, I use a PHP script to post the data to the CGI. This should be the same as posting to the CGI from a form, but it's not.

 

When I post to the CGI program using a PHP script instead of an HTML form, I get an intermediate page which, instead of transparently redirecting, says: "302 Found: The document has moved here" where "here" is a link to where it should have automatically redirected. The user is forced to click, which I do not want.

 

Can someone enlighten me as to why the "Location" header works correctly when a form posts to the CGI, but not when a PHP script posts to it?? Any insight you can give me would be greatly appreciated!!

 

Alternatively, I could find a way to communicate back to my PHP script the result code the CGI generates and do the redirect there, but I can't figure out how to do that, either.

 

Link to comment
Share on other sites

I wrote to the author of CURL with this question, since he clearly knows the answer. He quickly sent me back a reply of very little help because I don't understand it. He just referred me to the section of RFC2616 on 302 redirects. It says this:

 

10.3.3 302 Found

 

  The requested resource resides temporarily under a different URI.

  Since the redirection might be altered on occasion, the client SHOULD

  continue to use the Request-URI for future requests.  This response

  is only cacheable if indicated by a Cache-Control or Expires header

  field.

 

  The temporary URI 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: RFC 1945 and RFC 2068 specify that the client is not allowed

      to change the method on the redirected request.  However, most

      existing user agent implementations treat 302 as if it were a 303

      response, performing a GET on the Location field-value regardless

      of the original request method. The status codes 303 and 307 have

      been added for servers that wish to make unambiguously clear which

      kind of reaction is expected of the client.

 

That's lovely and I'm sure it's helpful to someone, but it may as well be written in Chinese, for all the good it does me.

 

This is as much as I can glean: If you get to the URI via a POST request, then you must redirect via GET or you'll get the dreaded intermediate page. I'd be happy to do this if I had the slightest clue HOW. I've found this same advice in several places, but no one gives a code example.

 

I post to my CGI and I redirect with this statement:

 

printf("Location: %s\n\n",loc);

 

What should I use instead??

 

Link to comment
Share on other sites

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.