Yuma Safari
Sunday, May 18, 2008
We recevied several reports in the last week about pages on the main Yuma site, blog, and forum that appeared as 404 (not found, unavailable) errors in your browser. A server restart addressed the issue, but only temporarily.
Initially the issue appeared to be browser-specific. Pages worked as expected in Firefox and Explorer, even as the same pages appeared as "not found" in Safari.
A deeper look into the Yuma Enterprise Server logs (start up with -v3 option for most verbose logging) revealed the answer. A comparison of a successful and failed request for the same page showed this difference in the responses:
Failed Response
HEADERS RETURNED:
Status: 302 Found
Content-Type: text/html; charset=utf-8
Content-Length: 5996
Success Response
HEADERS RETURNED:
<No status, so it will be set by the web server to 200.>
Content-Type: text/html; charset=utf-8
Content-Length: 5996
HTTP Status 302 is related to redirected requests. But there should have been no redirect involved in the request for the troubled pages. However, we do use redirects to force certain pages (namely the "Buy" page on the main Yuma site) to be served securely while all other pages are served insecurely. If you attempt to visit http://www.YumaDev.com/buy/, you should be redirected to a secure version of the same page. From the Buy page, if you visit any other page on the site, you will be redirected, as needed, to an insecure version of the same page (e.g. /product/) to improve speed.
If you visit a secure page with a https protocol in the address, there is no need for a redirect. The same is true if you visit an insecure page without the "s". We found the issue to be easily reproduced by first visiting the Buy page on the main Yuma site and then navigating to any insecure page on the site from there (or vice versa). That would force the insecure page to redirect to an insecure version of itself after initially being requested securely.
When a server sends a redirect status code, there is no need to send page content. The response header (including the 302 status code) is all the information the browser needs to know to hunt down the real content for the page. After the browser receives a redirect response header, it will make an imediate request for content at the url specified in the Location header value of the response.
The Yuma server was not clearing out the status variable after the redirect response was sent to the browser and before the next request was processed. So the 302 status code was effectively cached and inserted (improperly) in the response stream of the request that should have received a 200 status code and actual page content. That's where the browser differences appeared. Safari saw the 302 status code and assumed that it was a redirect response. But there was no Location header set, so it didn't know where to look for the actual content. Safari gave up and displayed a 404 error. The other browsers ignored the status code, saw that there was legitimate page content sent with the status code, and displayed that content as if there were no issue.
Yuma's page caching didn't help. Yuma, thinking it had successfully processed a request for the page in question, cached the flawed response that included the 302 status code. Every Safari site visitor from that point forward who visited the flawed url (whether or not they first visited the Buy page), received the cached response from the server and saw the same 404 error. A server restart addressed the issue temporarily because the server cache is cleared between restarts.
We have now addressed the issue in the Yuma Enterprise Server and all of our Yuma pages should be displaying correctly again across borwsers. But don't take my word for it, try visiting an insecure page on the site and then visit the Buy page. As long as you're on the Buy page... Hey look! A pre-order discount of 20% on Yuma during the public beta period? Hmm, didn't I hear that the public beta period is winding down. :-)
Special thanks to all of those who reported the unusual site behavior to us! Although this blog post is really about our bugs, please note the value of the Yuma logs in helping to track down issues in your sites.
I recognize that the secure/insecure redirect technique will probably be useful to other Yuma developers so I'll make a separate entry covering that technique soon.
Initially the issue appeared to be browser-specific. Pages worked as expected in Firefox and Explorer, even as the same pages appeared as "not found" in Safari.
A deeper look into the Yuma Enterprise Server logs (start up with -v3 option for most verbose logging) revealed the answer. A comparison of a successful and failed request for the same page showed this difference in the responses:
Failed Response
HEADERS RETURNED:
Status: 302 Found
Content-Type: text/html; charset=utf-8
Content-Length: 5996
Success Response
HEADERS RETURNED:
<No status, so it will be set by the web server to 200.>
Content-Type: text/html; charset=utf-8
Content-Length: 5996
HTTP Status 302 is related to redirected requests. But there should have been no redirect involved in the request for the troubled pages. However, we do use redirects to force certain pages (namely the "Buy" page on the main Yuma site) to be served securely while all other pages are served insecurely. If you attempt to visit http://www.YumaDev.com/buy/, you should be redirected to a secure version of the same page. From the Buy page, if you visit any other page on the site, you will be redirected, as needed, to an insecure version of the same page (e.g. /product/) to improve speed.
If you visit a secure page with a https protocol in the address, there is no need for a redirect. The same is true if you visit an insecure page without the "s". We found the issue to be easily reproduced by first visiting the Buy page on the main Yuma site and then navigating to any insecure page on the site from there (or vice versa). That would force the insecure page to redirect to an insecure version of itself after initially being requested securely.
When a server sends a redirect status code, there is no need to send page content. The response header (including the 302 status code) is all the information the browser needs to know to hunt down the real content for the page. After the browser receives a redirect response header, it will make an imediate request for content at the url specified in the Location header value of the response.
The Yuma server was not clearing out the status variable after the redirect response was sent to the browser and before the next request was processed. So the 302 status code was effectively cached and inserted (improperly) in the response stream of the request that should have received a 200 status code and actual page content. That's where the browser differences appeared. Safari saw the 302 status code and assumed that it was a redirect response. But there was no Location header set, so it didn't know where to look for the actual content. Safari gave up and displayed a 404 error. The other browsers ignored the status code, saw that there was legitimate page content sent with the status code, and displayed that content as if there were no issue.
Yuma's page caching didn't help. Yuma, thinking it had successfully processed a request for the page in question, cached the flawed response that included the 302 status code. Every Safari site visitor from that point forward who visited the flawed url (whether or not they first visited the Buy page), received the cached response from the server and saw the same 404 error. A server restart addressed the issue temporarily because the server cache is cleared between restarts.
We have now addressed the issue in the Yuma Enterprise Server and all of our Yuma pages should be displaying correctly again across borwsers. But don't take my word for it, try visiting an insecure page on the site and then visit the Buy page. As long as you're on the Buy page... Hey look! A pre-order discount of 20% on Yuma during the public beta period? Hmm, didn't I hear that the public beta period is winding down. :-)
Special thanks to all of those who reported the unusual site behavior to us! Although this blog post is really about our bugs, please note the value of the Yuma logs in helping to track down issues in your sites.
I recognize that the secure/insecure redirect technique will probably be useful to other Yuma developers so I'll make a separate entry covering that technique soon.