4

I'm getting errors where viewstate couldn't be decoded, and some of the errors trace to the fact that http post data was truncated at exactly 48K (49152) bytes.

This was listed as one of the fixed bugs in .NET 2.0 SP1. I currently have .NET 3.5 SP1.

This problem doesn't seem to happen with every post. Any ideas?

KB 945757 Problems that are fixed in the .NET Framework 2.0 Service Pack 1

KB 925248 FIX: The data in a POST request is truncated to 49,152 bytes when an ASP.NET-connected application receives the POST request

EDIT: Caught one of these errors in my error logs after I added encoding designation to the form. It shows the content-type was properly set to url-encoded, and the content-length was over 49152. But the dump of post data in the error log was again exactly 49152 bytes. I was able to re-create this by clicking the submit button several times from the page. I think the user did this because the page processes very slowly for some reason (was much faster before). It's likely the subsequent submissions that encountered this truncation. My fix might be to make the page fast again and/or disable the button from the first click.

Community
  • 1
  • 1
user1066127
  • 93
  • 1
  • 7
  • compress it, cut it, disable the non use viewstate data, re-design your program to not post this huge amount of data. – Aristos Jan 20 '12 at 20:51
  • @Aristos, unfortunately it's already compressed, and the code is inherited and big, change won't happen soon enough. On the other hand 48K just doesn't seem a reasonable limit on post data, viewstate or not. – user1066127 Jan 21 '12 at 00:00

2 Answers2

1

I do know that IIS5 had this problem, it would truncate all data above 48Kb except if the form was sent as application/x-www-form-urlencoded, try to set this as your content-type like:

<form accept-charset="utf-8" 
      enctype="application/x-www-form-urlencoded" ... >

</form>

The pen-tester can bring this issue up.

If you also search for HTTP Smuggling you will find the same issue.

you can read more info on HTTP Smuggling.

balexandre
  • 73,608
  • 45
  • 233
  • 342
  • Do you know if IIS6 still has the bug? That's what we're using. – user1066127 Jan 20 '12 at 21:14
  • don't have an IIS6 to test, only 7. but, did you try the form attribute `enctype`, does it work correctly? – balexandre Jan 21 '12 at 06:16
  • Yes I did add enctype. Don't know if it fixed the problem, because it was a random error that didn't happen all the time. – user1066127 Jan 23 '12 at 18:38
  • log everything until you find if it still happens... either use IIS Logs or a custom log... keep an eye on it, but theoretically, it should avoid the problem with this trick. – balexandre Jan 23 '12 at 19:21
1

i ran into this once and it turned out it's the browser that is truncating it!

i don't remember which one anymore though. I want to say it was firefox, but i can't be sure.

the fix was to change the content type of the form to multipart/form-data.

Patricia
  • 7,752
  • 4
  • 37
  • 70
  • All of my users are on various versions of IE, and this problem was reported at least for IE7 and 8. But I haven't seen one from IE9, though I only have a small number of samples. – user1066127 Jan 20 '12 at 21:20
  • is your form type multipart? like i said, i don't remember if it was firefox for sure. check your form type – Patricia Jan 23 '12 at 14:14
  • When I check in F12 and Fiddler, the form is url encoded, not multipart. But then again I've never seen this error happen myself, I only see this in error reports (emailed to me by the site) that indicate the postdata is cut off. – user1066127 Jan 23 '12 at 18:36
  • like balexandre change it over and keep an eye on your logs. – Patricia Jan 23 '12 at 20:30