Loading ...
Sorry, an error occurred while loading the content.

1964Arguments truncated semi-randomly

Expand Messages
  • Warren Young
    Mar 3, 2005
    • 0 Attachment
      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@...
      For additional commands, e-mail: asp-help@...
    • Show all 3 messages in this topic