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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to