[SOT] Strange browser behavior

[Matthew Pressly]

I am using a mod_perl content handler to implement
a series of forms.  The first request from a particular browser 
is always a GET that provides some required parameters in the
URL.  From then on, all parameters are passed as hidden form
variables, and only POSTs should occur.

If the browser accepts cookies, a unique session ID is stored
in a long lived cookie and is also logged in the access log,
strictly for tracking (no session data associated with it).
This is not 100% reliable because not everyone accepts cookies,
but it works enough of the time that I can track most of the
requests by this ID.

99.9% (roughly) of the time, everything works fine and the 
correct sequence is followed:
GET /formseries?a=123b=234
POST /formseries   (a=123, b=234 passed in post vars)
POST /formseries   (a=123, b=234 passed in post vars)
POST /formseries   (a=123, b=234 passed in post vars)
POST /formseries   (a=123, b=234 passed in post vars)
POST /formseries   (a=123, b=234 passed in post vars)

The problem is that there are a few request trails per day,
where the following sequence is followed instead:
GET /formseries?a=123b=234
POST /formseries(a=123, b=234 passed in post vars)
POST /formseries(a=123, b=234 passed in post vars)
POST /formseries(a=123, b=234 passed in post vars)
GET /formseries (required parameters not passed on this request)

The GET fails because the handler does not have the required
parameters it needs to pull info from the database.

An incomplete of user agents that the problem occurs with are:
  Mozilla/4.0 (compatible; MSIE 5.0; Windows 98; DigExt)
  Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)
  Mozilla/4.0 (compatible; MSIE 5.5; Windows 98; Win 9x 4.90)

One other piece of evidence is that the Referer is empty
on the erroneous GET request.

I have tried but been unable to reproduce the failing
request sequence using IE, even using back, forward, and reload
button in a number of sequences.

My questions are, is there some IE anomaly or some anomalous way
of configuring or using IE that can cause it to all of a sudden
do a GET instead of a POST (anything short of manually entering
the url)?  Could a proxy be causing the problem (a small subset
of the failing requests to seem to be coming through proxies)?
  
Also, is there anything more I could track that would give
more insight into the problem?  Currently the content handler
does detect that the required parms are missing and then dumps
the complete request and timestamp into the error log.

Also, please let me know if there is a more appropriate forum
to ask this question.

--
Matthew Pressly

RE: [SOT] Strange browser behavior

[Nick Challoner]

 My questions are, is there some IE anomaly or some anomalous way
 of configuring or using IE that can cause it to all of a sudden
 do a GET instead of a POST (anything short of manually entering
 the url)?

User bookmarking the page (well, adding to favourites considering we're
talking about IE) and then returning to it via the bookmark?

...Nick.

-- 
Nick Challoner
[EMAIL PROTECTED]

Re: [SOT] Strange browser behavior

[Perrin Harkins]

Nick Challoner wrote:


My questions are, is there some IE anomaly or some anomalous way
of configuring or using IE that can cause it to all of a sudden
do a GET instead of a POST (anything short of manually entering
the url)?


User bookmarking the page (well, adding to favourites considering we're
talking about IE) and then returning to it via the bookmark?



It may also no longer send POST data or give the option of no longer 
sending it if you go back to a page resulting from a POST after a 
certain amount of time.

- Perrin

Re: [SOT] Strange browser behavior

[Matthew Pressly]

On Thu, Nov 21, 2002 at 02:32:41PM -0500, Perrin Harkins wrote:
 Nick Challoner wrote:
 
 My questions are, is there some IE anomaly or some anomalous way
 of configuring or using IE that can cause it to all of a sudden
 do a GET instead of a POST (anything short of manually entering
 the url)?
 
 
 User bookmarking the page (well, adding to favourites considering we're
 talking about IE) and then returning to it via the bookmark?
 
 
 It may also no longer send POST data or give the option of no longer 
 sending it if you go back to a page resulting from a POST after a 
 certain amount of time.
 
 - Perrin

In looking at these replies and going back through the logs 
more, I think there are multiple failure mechanisms rather than
a single one.  Both the cases above may be ocurring to some degree.
A segment looks like it may also be caused by proxies.  Browser
caching may also be causing some of it, and there may be other
causes as well.  Setting $r-no_cache(1) did not solve the problem,
though there is a chance it may have alleviated it somewhat..

Since there is a session id generated for browsers that have
cookies enabled, I'm planning to stow away the parameters 
in either the database or File::Cache on the first GET
request when parameters are available, then fall back to
looking there on subsequent requests if and only if the
parameters are missing (not in query string and not in POST
data).  This should fix most of the currently
failing cases without much more code.

Thank you all for your help.

--
Matthew Pressly