Closed Bug 26723 Opened 25 years ago Closed 25 years ago

form information isn't always posted correctly ?

Categories

(Core :: DOM: Core & HTML, defect, P3)

Product:
Core
Component:
DOM: Core & HTML
Type:
defect

Tracking

()

Status:
VERIFIED DUPLICATE of bug 18728

People

(Reporter: d.cary, Assigned: pollmann)

References

(
URL
)

Details

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: 25 years ago
Resolution: --- → DUPLICATE
Verified 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.