Closed Bug 37744 Opened 25 years ago Closed 25 years ago

form submission fails on long posts (over 8Kb)

Categories

(Core :: Networking, defect, P3)

defect

Tracking

()

VERIFIED FIXED

People

(Reporter: myk, Assigned: ruslan)

References

()

Details

Attachments

(2 files)

Overview Description: Form submission fails with the message "The operation timed out when attempting to contact [server name]" when submitting a form with a TEXTAREA that has more than a certain number of characters in it, a certain number of which are tags. Steps to Reproduce: Load test case and submit first form. Actual Results: Error message appears after approx. one minute delay. Expected Results: Form is submitted and page reappears. Build Date & Platform Bug Found: Linux 2000-04-28-09 Additional Builds and Platforms Tested On: Linux M15 - doesn't work either Linux Netscape 4.7 - works fine Additional information: I'm not sure exactly what is causing the problem, but it appears to be some combination of the length of the string in the TEXTAREA and the number of tags included in that string (or their length). The type of tag is not important. I have succeeded in breaking Mozilla using <P> tags as well as XML tags specific to the application in which I first discovered the problem. The test case uses the nonsensical tag <foofoofoofoofoofoofoo>.
Attached file test case (deleted) —
reassigning
Assignee: rods → pollmann
Thanks for the awesome test case. See bug 38057.
Interestingly, tags cause the *URL encoded* string that is going to be submitted to the server be longer. For example, in your test case, "7739 total characters in TEXTAREA, including 1692" gets expanded to 8195 characters, exactly three bytes longer than 8Kbytes. I bet it is just the total number of characters sent to the server... Also fails on NT.
Severity: normal → major
Status: NEW → ASSIGNED
OS: Linux → All
Hardware: PC → All
Summary: form submission fails on TEXTAREA with long string containing tags → form submission fails on TEXTAREA with long string
Target Milestone: --- → M16
Above test case is the largest that succeeds, not the smallest that fails. :S Adding one more char in the text area causes me to fail. Since this is under 8Kb (including foo= before the text), I'm guessing that there may a limit to the post size, including HTTP headers. This may be a networking problem.
This post gets down into netlib but never succeeds in writing the bytes to the server. I traced it as far as this: nsHTTPPipelinedRequest::OnStopRequest ... rv = mTransport->AsyncWrite(mInputStream, this, (nsISupports*)(nsIRequest*)req->mConnection); ... The buffer in mInput Stream here has 8195 bytes in it (failing case) which includes the headers from Content-Type on down, then the form post data. Since this appears to be netlib post failing, I'm reassigning it to the netlib folks. Please let me know if I can help!
Assignee: pollmann → warren
Status: ASSIGNED → NEW
Component: Form Submission → Networking
Summary: form submission fails on TEXTAREA with long string → form submission fails on long posts (over 8Kb)
=> ruslan
Assignee: warren → ruslan
Fixed.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Although the test case now works, bug 39809 prevents me from verifying this is fixed in the application in which I originally found it, and that bug may be a regression caused by the fix for this bug given the time period in which it appeared. I'll wait to verify this bug until I see what happens to the other one.
->vladimire
QA Contact: ckritzer → vladimire
Verifying
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: