Currently showing entries with the tag: Flash
|
page 1 of 1
|
HTTP Status Code 307 - Temporary Redirect
August 19, 2007 • 9:41AM • permalink
I'm sure that many of you haven't gotten past the title before saying, "No, a HTTP Status Code of 302 is the Temporary Redirect." I'd like to briefly explain the difference between the two and show you how you can benefit from a 307 redirect. Please also note, that this is a temporary redirect and should probably be avoided in most production situations. You will see one case in particular below where this can be useful.
In .NET, the standard way to redirect between pages is to use the Response.Redirect() method. This implicitly flushes the Response buffer and instead of sending back HTML (with a status code 200 OK), it sends the user a 302 Found code, meaning the requested page was found, but under a different URI. The server also sends back the new URI in the Location header that should be subsequently retrieved by the client.
This works in most cases, except for one minor problem: the case when you're trying to POST data to the server. There are many ways around this problem (including changing it to a GET/QueryString combo), but if a POST is necessary a 307 Temporary Redirect status code will indicate to the browser that the POST method should be retained.
This can be very valuable when developing on a machine with Windows XP Pro (and hence IIS 5.1 which doesn't allow you to identify web sites with host headers.) Under IIS, I setup multiple projects with the directory schema C:\Inetpub\wwwroot\ProjectName\. In my code, I prefix all links with an Web.config driven value that indicates the subdirectory off the root that the project resides in. This way, I can use the value /ProjectName/ in dev and / in production and the links will work in both environments. I don't like to pass these values around though, so when I recently wrote a small Flash application specifically for one website, I wanted to hardcode the SWF to POST to 'http://www.domainname.com/'. It seemed like a lot of work at first, but with a 307 redirect, it was simple!
If the Flash file was hardcoded to POST to 'http://www.domainname.com/PageName.aspx', you just create a file in the localhost root directory (C:\Inetpub\wwwroot\ in my example) called PageName.aspx and run the following on Page_Load():
Response.StatusCode = 307;
Response.RedirectLocation = "/ProjectName/PageName.aspx";
This will allow proper testing in IIS 5.1 and will redirect to the correct page with a POST method and all associated form data.
One final note as to why this should only be used for testing. Part of the definition of a 307 status code directs that browsers should prompt the user of the redirect and allow them to replicate the action (for older browsers). Firefox, in particular, is one browser that fully supports the standard and prompts the user, asking if they want to allow the form data to be sent via a POST. Since this could lead to a very poor user experience, I would recommend limiting use of the 307 status code to development and testing environments only.
In .NET, the standard way to redirect between pages is to use the Response.Redirect() method. This implicitly flushes the Response buffer and instead of sending back HTML (with a status code 200 OK), it sends the user a 302 Found code, meaning the requested page was found, but under a different URI. The server also sends back the new URI in the Location header that should be subsequently retrieved by the client.
This works in most cases, except for one minor problem: the case when you're trying to POST data to the server. There are many ways around this problem (including changing it to a GET/QueryString combo), but if a POST is necessary a 307 Temporary Redirect status code will indicate to the browser that the POST method should be retained.
This can be very valuable when developing on a machine with Windows XP Pro (and hence IIS 5.1 which doesn't allow you to identify web sites with host headers.) Under IIS, I setup multiple projects with the directory schema C:\Inetpub\wwwroot\ProjectName\. In my code, I prefix all links with an Web.config driven value that indicates the subdirectory off the root that the project resides in. This way, I can use the value /ProjectName/ in dev and / in production and the links will work in both environments. I don't like to pass these values around though, so when I recently wrote a small Flash application specifically for one website, I wanted to hardcode the SWF to POST to 'http://www.domainname.com/'. It seemed like a lot of work at first, but with a 307 redirect, it was simple!
If the Flash file was hardcoded to POST to 'http://www.domainname.com/PageName.aspx', you just create a file in the localhost root directory (C:\Inetpub\wwwroot\ in my example) called PageName.aspx and run the following on Page_Load():
Response.StatusCode = 307;
Response.RedirectLocation = "/ProjectName/PageName.aspx";
This will allow proper testing in IIS 5.1 and will redirect to the correct page with a POST method and all associated form data.
One final note as to why this should only be used for testing. Part of the definition of a 307 status code directs that browsers should prompt the user of the redirect and allow them to replicate the action (for older browsers). Firefox, in particular, is one browser that fully supports the standard and prompts the user, asking if they want to allow the form data to be sent via a POST. Since this could lead to a very poor user experience, I would recommend limiting use of the 307 status code to development and testing environments only.
0 comments
|
page 1 of 1
|
