Closed Bug 26723 Opened 20 years ago Closed 20 years ago
form information isn't always posted correctly ?
I can use the above URI in Lynx and other competing web browsers to check physical addresses and find the correct zip+4 codes. (Rumor is that physical mail gets to its destination a day quicker if you write all 9 digits of the zip code on it, rather than only the first 5). Unfortunately, it doesn't seem to work in Mozilla (I just tried M13 for Linux and M13 for Win32). I'm guessing that Mozilla sends only some (or none ?) of the information I type in the form fields ? In particular, I type 1124 South Lewis Avenue Tulsa OK in the appropriate fields and then click "Process". When I use competing web browsers, the USPS then tells me the "normalized" address with the full zip+4 code and everything. When I use Mozilla for Win32, the USPS claims "The state you entered was not found in our database.". (I get a slightly different message when I use Mozilla on my Linux box). The login form at http://www.deja.com/my/pr.xp works fine in Mozilla. I wonder why this form works, but the USPS form doesn't ?
Reassigning to Warren.
Assignee: karnaze → warren
Jud, can you investigate?
Assignee: warren → valeski
Target Milestone: M14
reassigning to pollmann. our form post format is different from 4.x. This is why the server is choking. We're pre-pending the form element string with "Submit=Process" and we're *not* increasing the content-length to deal with this extra string. Here's 4.x: Content-length: 106 Firm=blah&Urbanization=&Delivery+Address=1221+Pearl+St&City=Boulder&State=CO&Zip +Code=80302&Submit=Process Here's 5.0: Content-Length: 106 Submit=Process&Firm=blah&Urbanization=&Delivery+Address=1221+Pearl+St&City=Bould er&State=CO&Zip+Code=80302
Assignee: valeski → pollmann
The content-length is correct here so that isn't the problem. You'll notice Submit=Process is in both nav's and our post data (see bug 18728 to see why they are out of order). I'll look into this and see why it's failing.
Well, it looks like the variable order is what is screwing up this CGI. I took Nav's post data and simply rearranged the variables to match ours, and got the "state not found" error. This is the first time I've seen a CGI affected by this bug. Marking this a duplicate. *** This bug has been marked as a duplicate of 18728 ***
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
Status: RESOLVED → VERIFIED
Component: HTML: Form Submission → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.