We have an ASP application which mostly works, but on one particular
form, POSTed updates are randomly ignored. I think we have the problem
isolated, but we're stuck for another reason. I'll take you through the
debug process so you know what the situation is so far.
- The symptom is that when $Request->{Method} eq 'POST', our code goes
through the hash referred to by $Request->Form looking to see what kind
of 'POST' it has received. In the failure case, we find that no form
elements at all are present in the referred-to hash. This is plainly
why the update is being ignored. The question is, why are there no
arguments in the hash?
- We tried sniffing HTTP packets to see if there was a difference
between the success and failure cases. Viewed as a stream, there is no
difference: the arguments are definitely going down the wire. Here's
the start of a typical HTTP POST request:
> POST /bla.asp HTTP/1.0
> Host: bla
> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041217
> Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
> Accept-Language: en-us,en;q=0.5
> Accept-Encoding: gzip,deflate
> Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
> Keep-Alive: 300
> Connection: keep-alive
> Referer: http://bla/bla.asp
> Cookie: session-id=03fab6464ed0a18ba861190243a9de9f
> Content-Type: application/x-www-form-urlencoded
> Content-Length: 2343
>
> channel=28&r113_z10=on&....
I made it a quotation so my mailer wouldn't wrap lines. Some names
changed to protect the innocent. :) The elipsis at the end indicates
many other arguments. This particular ASP page shows something on the
order of 1200 check boxes in a grid, and there is one "rXXX_zXX"
argument for each checked box.
- I set ASP's debug level to -1 and diffed the logs between the success
and failure cases. The only significant change is this one:
Success: "read 2343 bytes, tried 2343 bytes"
Failure: "read 1387 bytes, tried 2354 bytes"
That message is printed by ASP/Request.pm, line 232. This is plainly
the culprit: the read() call above this line isn't returning the entire
HTTP request in a single call.
The main reason I'm posting to the list is because it isn't clear to me
what the cleanest way to fix this is. I could hack some loop on that
read() call, but I'd rather Josh chimed in on this one.
---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org
form, POSTed updates are randomly ignored. I think we have the problem
isolated, but we're stuck for another reason. I'll take you through the
debug process so you know what the situation is so far.
- The symptom is that when $Request->{Method} eq 'POST', our code goes
through the hash referred to by $Request->Form looking to see what kind
of 'POST' it has received. In the failure case, we find that no form
elements at all are present in the referred-to hash. This is plainly
why the update is being ignored. The question is, why are there no
arguments in the hash?
- We tried sniffing HTTP packets to see if there was a difference
between the success and failure cases. Viewed as a stream, there is no
difference: the arguments are definitely going down the wire. Here's
the start of a typical HTTP POST request:
> POST /bla.asp HTTP/1.0
> Host: bla
> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041217
> Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
> Accept-Language: en-us,en;q=0.5
> Accept-Encoding: gzip,deflate
> Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
> Keep-Alive: 300
> Connection: keep-alive
> Referer: http://bla/bla.asp
> Cookie: session-id=03fab6464ed0a18ba861190243a9de9f
> Content-Type: application/x-www-form-urlencoded
> Content-Length: 2343
>
> channel=28&r113_z10=on&....
I made it a quotation so my mailer wouldn't wrap lines. Some names
changed to protect the innocent. :) The elipsis at the end indicates
many other arguments. This particular ASP page shows something on the
order of 1200 check boxes in a grid, and there is one "rXXX_zXX"
argument for each checked box.
- I set ASP's debug level to -1 and diffed the logs between the success
and failure cases. The only significant change is this one:
Success: "read 2343 bytes, tried 2343 bytes"
Failure: "read 1387 bytes, tried 2354 bytes"
That message is printed by ASP/Request.pm, line 232. This is plainly
the culprit: the read() call above this line isn't returning the entire
HTTP request in a single call.
The main reason I'm posting to the list is because it isn't clear to me
what the cleanest way to fix this is. I could hack some loop on that
read() call, but I'd rather Josh chimed in on this one.
---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org