truncated form POST

[EricY]

We have an intermittent issue where it appears that the form is being
truncated after exactly 1008 characters. This causes server-side code
to fail as it is expecting certain fields to exist. To figure out
what is happening we started logging the entire form to our log table
when an error occurs. What we are seeing is that the form is being
cut off after 1,008 characters.

When I say it is cut off, I mean it looks like this example:

A normal form:
"txtInput1=123&txtInput2=456&txtInput3=789"

Truncated form:
"txtInput1=123&txtInput2=456&txtIn"

The cutoff point varies in the form depending on the size of the field
values, but the length of the value stored is always 1008 characters.
We wrapped tags around the form so that we would be sure to capture
the entire thing when we logged it. Forcing an error on a dev server
so that a correct form would be logged shows that a normal form is
around 1,500 characters or so.

This is happening on a classic asp page but we also have .net 2.0 code
running in the same app. Servers are running windows 2003.

Has anyone ever experienced this?

Thanks for any help...

Eric

 

[Bob Barrows]

We have an intermittent issue where it appears that the form is being
truncated after exactly 1008 characters. This causes server-side code
to fail as it is expecting certain fields to exist. To figure out
what is happening we started logging the entire form to our log table
when an error occurs. What we are seeing is that the form is being
cut off after 1,008 characters.

When I say it is cut off, I mean it looks like this example:

A normal form:
"txtInput1=123&txtInput2=456&txtInput3=789"

Truncated form:
"txtInput1=123&txtInput2=456&txtIn"

Do you know what the untruncated submission was supposed to look like?
Are you using GET? Those look like querystrings ...

 

[EricY]

Do you know what the untruncated submission was supposed to look like?
Are you using GET? Those look like querystrings ...

--
HTH,
Bob Barrows- Hide quoted text -

- Show quoted text -

Thanks Bob.

Yes, I know what the full submission is supposed to look like, and
it's definitely being truncated.

The form method is POST, but in ASP you can simply do a:

Response.write (Request.Form) and it will spit out the entire
form...although what it spits out looks like a querystring.

On "good" form submissions the length of Request.Form is over 1,500
chars... on bad submissions it's exactly 1,008 chars.

Eric

 

[Bob Barrows]

Thanks Bob.

Yes, I know what the full submission is supposed to look like, and
it's definitely being truncated.

I was trying to determine if there were any invalid characters in the
form submission that would cause it to be truncated if GET was being
used. But I now see you are using POST so it's no longer relevant.

The form method is POST, but in ASP you can simply do a:

Response.write (Request.Form) and it will spit out the entire
form...although what it spits out looks like a querystring.

I prefer to do a loop like this:
<%
for each x in Request.Form
Response.Write("<br>" & x & " = " & Request.Form(x))
next
%>

If you're still missing data, then I'm at a loss ... wait, is every
submission over 1008 characters truncated? Or only some of them?

 

[Bob Barrows]

See if this is relevant:
http://classicasp.aspfaq.com/forms/what-is-the-limit-on-form/post-parameters.html

 

[EricY]

I was trying to determine if there were any invalid characters in the
form submission that would cause it to be truncated if GET was being
used. But I now see you are using POST so it's no longer relevant.



I prefer to do a loop like this:
<%
    for each x in Request.Form
        Response.Write("<br>" & x & " = " & Request.Form(x))
    next
%>

If you're still missing data, then I'm at a loss ... wait, is every
submission over 1008 characters truncated? Or only some of them?

--
HTH,
Bob Barrows- Hide quoted text -

- Show quoted text -

Thanks for your help Bob. The issue only happens once or twice per
day on this particular page (out of possibly 1,000+ submissions/day).
This form submission is *always* greater than 1008 characters - even
if the form elements have no values in them the form size is
approximately 1,100 chars with just the form element names. 99.9% of
the time the form submits fine with no issues. In fact, I can not
reproduce the error myself but it's obviously happening as reported by
our logs. But the 0.1% of the time it happens the form seems to be
cut off at 1008 characters. Perhaps we should change the logging to
do the loop you mentioned, possibly to rule out or even identify
something else that might be going on. Note that we've never seen
this in any of our dev or QA environments; only in our production
environment.

However, I'm fairly confident that the elements are being truncated as
expected and here is why. Three of the form elements make up a date
field; txtMonth, txtDay, txtYear. We first noticed the error b/c
sometimes we were getting an invalid date error when we combined those
fields to make a date value. I started logging the values of those
fields and was always getting empty strings...eventually we expanded
the logging to include the entire form and the date fields aren't even
there (they appear at the end of the form so they get truncated when
the issue occurs).

I don't know if this is related, but occasionally we get "invalid
postback or callback argument" errors in the .net code which from what
I can tell could be caused by truncated form. Maybe coincidence,
maybe something related?

Sorry to be so long-winded... thanks again!

Eric

 

[EricY]

See if this is relevant:http://classicasp.aspfaq.com/forms/what-is-the-limit-on-form/post-par...

Thanks for that info. Unfortunately this isn't our issue. We have a
pretty high limit on our form size to allow for file uploads. I think
we have it set to something like 50MB (not exact, but it's in that
ballpark).

Eric

 

[Daniel Crichton]

EricY wrote on Fri, 24 Apr 2009 06:45:16 -0700 (PDT):

Thanks for your help Bob. The issue only happens once or twice per day
on this particular page (out of possibly 1,000+ submissions/day).
This form submission is *always* greater than 1008 characters - even if
the form elements have no values in them the form size is approximately
1,100 chars with just the form element names. 99.9% of the time the
form submits fine with no issues. In fact, I can not reproduce the
error myself but it's obviously happening as reported by our logs. But
the 0.1% of the time it happens the form seems to be cut off at 1008
characters. Perhaps we should change the logging to do the loop you
mentioned, possibly to rule out or even identify something else that
might be going on. Note that we've never seen this in any of our dev
or QA environments; only in our production environment.

However, I'm fairly confident that the elements are being truncated as
expected and here is why. Three of the form elements make up a date
field; txtMonth, txtDay, txtYear. We first noticed the error b/c
sometimes we were getting an invalid date error when we combined those
fields to make a date value. I started logging the values of those
fields and was always getting empty strings...eventually we expanded
the logging to include the entire form and the date fields aren't even
there (they appear at the end of the form so they get truncated when
the issue occurs).

I don't know if this is related, but occasionally we get "invalid
postback or callback argument" errors in the .net code which from what
I can tell could be caused by truncated form. Maybe coincidence, maybe
something related?

Sorry to be so long-winded... thanks again!

Eric

Are these posts from known client machines? Or are they from all over the
place? Can you log the request headers too? Maybe there's a commonality to
all these requests, such as requests coming through a proxy server that
restricts POST data to 1008 characters.

 

[EricY]

EricY wrote  on Fri, 24 Apr 2009 06:45:16 -0700 (PDT):

 >> EricY wrote:


 >>>>> We have an intermittent issue where it appears that the form is
 >>>>> being truncated after exactly 1008 characters. This causes
 >>>>> server-side code to fail as it is expecting certain fields to
 >>>>> exist. To figure out what is happening we started logging the
 >>>>> entire form to our log table when an error occurs. What we are
 >>>>> seeing is that the form is being cut off after 1,008 characters.

 >>>>> When I say it is cut off, I mean it looks like this example:

 >>>>> A normal form:
 >>>>> "txtInput1=123&txtInput2=456&txtInput3=789"

 >>>>> Truncated form:
 >>>>> "txtInput1=123&txtInput2=456&txtIn"

 >>>> Do you know what the untruncated submission was supposed to look
 >>>> like? Are you using GET? Those look like querystrings ...

 >>> Thanks Bob.

 >>> Yes, I know what the full submission is supposed to look like, and
 >>> it's definitely being truncated.

 >> I was trying to determine if there were any invalid characters in the
 >> form submission that would cause it to be truncated if GET was being
 >> used. But I now see you are using POST so it's no longer relevant.

 >>> The form method is POST, but in ASP you can simply do a:

 >>> Response.write (Request.Form) and it will spit out the entire
 >>> form...although what it spits out looks like a querystring.

 >> I prefer to do a loop like this:
 >> <%
 >>     for each x in Request.Form         Response.Write("<br>" & x & "
 >> = " & Request.Form(x))
 >>     next %>

 >> If you're still missing data, then I'm at a loss ... wait, is every
 >> submission over 1008 characters truncated? Or only some of them?

 >> --
 >> HTH,
 >> Bob Barrows- Hide quoted text -

 >> - Show quoted text -






Are these posts from known client machines? Or are they from all over the
place? Can you log the request headers too? Maybe there's a commonality to
all these requests, such as requests coming through a proxy server that
restricts POST data to 1008 characters.

Dan,

These posts are from all over the place. Our site is a subscription-
based app with subscribers all over the country. I haven't noticed
any commonality across clients, but I haven't really focused on that.

I'll see if I can start logging the request headers. Will likely have
to wait for our next code release though - probably in a few weeks or
so.

Thanks for the suggestion.

Eric

 

[Adrienne Boswell]

These posts are from all over the place. Our site is a subscription-
based app with subscribers all over the country. I haven't noticed
any commonality across clients, but I haven't really focused on that.

Perhaps it's a browser problem. Have a look at UA strings to see if there
is a commonality there.