Old or expired pages are served by the browser/proxy cache
Closed this issue · 13 comments
Some users experience often that their pages are returned with "expired transaction ID" error.
Issue was analyzed and it happens like this example:
- user asks for an exam page, it is generated wit transaction ID 000011, written into transaction file but the user receives an older exam page from cache (browser or proxy, not clear which) with an expired&invalid transaction ID 000009.
- Requesting the evaluation of exam page(transaction 000009) will get "expired transaction", while the legal transaction ID 11 remains in the file, until it expires as time and is by first cleaning task executed.
Unsatisfactory tried solutions will be added.
Using the new signed transaction ids we will know for sure that expired transactions are really expired and not "generated"
Result: now with the increased granularity of error types, the expiry reason is ruled out. It does not happen because expired transaction.
Error sequence:
- User enters in root page
root page has transaction 00CC36_56_32_14_24_2_116_%2BLlO0EI3gWXaAwwMEiaSvA
sim_transaction has storeed same 00CC36_56_32_14_24_2_116_%2BLlO0EI3gWXaAwwMEiaSvA - in root page use cliks on exam(e.g III-R)
effect: Browser sends a GET to the server:
/cgi-bin/sim_gen3r.cgi?transaction=00CC36_56_32_14_24_2_116_%2BLlO0EI3gWXaAwwMEiaSvA - server consumes transaction 00CC36_56_32_14_24_2_116_%2BLlO0EI3gWXaAwwMEiaSvA from sim_transaction
- server writes in sim transaction an exam transaction: 00CC37_7_18_16_24_2_116_/PtIHr5wgCI6OazuESUZMA owene 7 7 18 16 24 2 116 8 22 25 28 35 37 41 44 46 52 4 12 19 36 42 47 57 64 32 36 40 45 49 55 64 65 74 77 86 88 97 108 120 124 128 132 139 150 K
- broswer receives "formularul a fost deja folosit odata"
final status on server:
next transaction: 00CC38
exam transaction 00CC37_xxx still in sim_transaction but user has no matching form.
Scenarios:
- Browser sends 2x the GET. Is this possible? Server processes the 1st, make the exam transaction. 2nd GET has a consumed transaction and the browser receives the error message for the 2nd GET. where is the answer for the first GET lost?
- Other scenario?
Confirm, Browser(Mozilla) tracing tools shows that browser sends 2 GET requests. second has Cache-Control:"max-age=0"
The thing is that the first GET is answered with the exam page (!!!)
To check if this page has something defect inside and triggers second GET emission.
But after/before the answer, the 2nd GET goes (to check timing) and answer comes with "form already used"
Checked two response html page that reaches the browser but is not displayed: it's a perfectly valid page so cannot blame for the moment missing images.
2.3.1.2. GET
GET is the standard request method for retrieving a document via HTTP on the Web. When you click on a hyperlink, type a location into your browser, or click on a bookmark, the browser generally creates a GET request for the URL you requested. GET requests are intended only to retrieve resources and should not have side effects. They should not alter information maintained on the web server; POST is intended for that purpose. GET requests do not have a content body.
In practice, some CGI developers do not understand nor follow the policy that GET requests should not have side effects, even though it is a good idea to do so. Because web browsers assume that GET requests have no side effects, they may be carefree about making multiple requests for the same document. For instance, if the user presses the browser's "back" button to return to a page that was originally requested via GET and is no longer in the browser's cache, the browser may GET a new copy. If the original request was via POST, however, the user would instead receive a message that the document is no longer available in the cache. If the user then decides to reload the request, he or she will generally receive a dialog confirming that they wish to resend the POST request. These features help the user avoid mistakenly sending a request multiple times when the request would modify information stored on the server.
Report: changing from GET to POST does not solve the problem, it seems that the server now receives multiple POST requests, but tracer shows that not from the browser, just triggered by the POST message from browser.
Logs show that from some POST messages sent by the browser, an "empty" GET message arrives at same time(shortly before or after the POST). GET is generated by some entity in the middle
This should be treated better as DoS.
Answering the empty GET message with a Status: 204 No Content message, seems solving the problem (solution under test)
The browser does not change the content when it receives the 204 status, so for my application it solves the problem.
solved.
reopen to merge with the newer
cannot merge, just reference. Closed.