'On certain sites when a mongo cursor error occurs a plain page is returned with the error, site installation details and most critically a 200 status code. With the 200 status code the page is cached in Varnish and Akamai as a "good" page. The frequency of this should be lowered by implementing Memcache but the errors still need to return error codes to prevent being cached.'
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | 1702544-fail_500-4.patch | 1.78 KB | fgm |
| #3 | 1702544-fail_500-3.patch | 1.8 KB | fgm |
| #2 | 1702544-fail_500-2.patch | 738 bytes | fgm |
| #1 | mongodb_cache-throw_error-1702544-2.patch | 750 bytes | cyberswat |
Comments
Comment #1
cyberswat commentedComment #2
fgmRerolled on today's HEAD. Also, I think a 503 (Service unavailable) is more accurate than an 502, which is mean for HTTP proxies and gateways, not origin servers.
I'm not a fan of killing the whole page for a mongodb connection failure to a cache, though : the page might be able to continue and finish being served normally from uncached content if cache is the only service routed to this specific MongoDB instance. Or at least finish the page release as in
drupal_page_footer().Any feedback ?
Comment #3
fgmHere is a new version on today's HEAD which does return a 503 on exception, but does it at the end of the page cycle, not exiting in the middle of the page cycle. Any opinions ?
Comment #4
fgmRerolled on today's updated 7.x-1.x. Current tests pass, but I feel such a change would warrant a test case.
Comment #5
fgmThe current version fails to catch errors during bin construction, such as those occurring is the server is not available.
Comment #7
fgmFix added and committed to today's 7.x-1.x HEAD, thanks.