Closed Bug 101666 Opened 23 years ago Closed 23 years ago

Mozilla receives different page after submiting this form. (HTTPS).

Categories

(Core :: Networking: HTTP, defect, P1)

Product:
Core
Component:
Networking: HTTP
Platform:
x86
All
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.0

People

(Reporter: mgalli, Assigned: darin.moz)

References

(
URL
)

Details

(Keywords: topembed+, Whiteboard: topsite, partner, [adt2])

Attachments

(2 files)

HTTP log from a Nordstrom.com session
(deleted), text/plain
Details
http log segment
(deleted), text/plain
Details
Tested with Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4+) Gecko/20010925 ---------- Please go to the above URL and try to checkout. with Mozilla, you will have a different URL after you submit the form data. It says: Object Moved. If you use IE you will have the proper web page. Dave used a proxy and realized that with Mozilla there is one HTTP 100 code returned after the form posting. Please help us find out if this is something in the client or something that we can talk with their webmaster/engineeers to have this fixed in the web site.
Adding roger,.. do you have the same problem here?
Yeap! Same problem. Using netscape 6.1 for linux. More info on the use of the 100 (Continue) Status can be found at: http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html#sec8.2.3It looks like the site is performing just a redirect after the login form post, so if they use a redirect status code, it will probably work on current versions of mozillas/netscapes...
Thanks Roger for this. http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html#sec8.2.3 Dave, do you have an idea what's going on with that page? Seems like when we access that page with IE there is no 100 status. I am planning to use a proxy with log option also and conduct some tests here.
Setting topembed.
Keywords: topembed
cc'ing folks. does this look content or client related?
is this a recent regression?
please enable NSPR logging for HTTP in a recent nightly build... export NSPR_LOG_MODULES=nsHttp:5 export NSPR_LOG_FILE=http.log run through the steps to repro this problem and then attach the file http.log to this bug report. this log file may help reveal the source of the problem. thanks, darin
Darin - I'd be happy to provide an HTTP log - is there a way to enable logging for Win98?
Jud - I don't think this is a recent regression - I get the same behavior on N6.1 / Win98.
Status: UNCONFIRMED → NEW
Ever confirmed: true
dave: open up a DOS prompt, and... C:\> set NSPR_LOG_MODULES=nsHttp:5 C:\> set NSPR_LOG_FILE=C:\httplog.txt C:\> cd path\to\mozilla C:\> .\mozilla
Darin - Using N6.1, these instructions just give me an empty log file. However, the following is HTTP that I captured previously using a proxy server: HTTP/1.1 100 Continue Server: Microsoft-IIS/5.0 Date: Wed, 26 Sep 2001 00:32:35 GMT Pragma: No-cache Cache-control: No-cache Set-Cookie: SessionUUID=5e4ab0e5-a912-4ae5-8cbb-8f49f26381e9; path=/; domain=nordstrom.com HTTP/1.1 200 Ok <head><title>Object moved</title></head> <body><h1>Object Moved</h1>This object may be found <a HREF="https://secure.nordstrom.com/checkout/signin.asp">here</a>.</body> The same request using MSIE gives a single 302 response, and this does not seem to depend on the UA string.
dave: the logging feature was not present in NS6.1, can you please try a recent nightly build. thx!
->darin
Assignee: neeti → darin
-> 0.9.6
Status: NEW → ASSIGNED
Priority: -- → P1
Target Milestone: --- → mozilla0.9.6
Blocks: 64833
Now when I try to go to the checkout page, the browser just spins (using 10/19 0.9.4 branch build, and also using a recent trunk build). It doesn't come back with the Object Moved message. To reproduce, go to http://store.nordstrom.com/product/product.asp?styleid=2786682&category=2376778~2372807~2372817~2375558&PrevStyleID=none&NextStyleID=2784430 and choose a size / color combination, then "Add to Shopping Bag". Then, on the following page, click the "Proceed To Checkout" button. At this point, the browser just spins for me. I will attach the HTTP log.
Attached file HTTP log from a Nordstrom.com session (deleted) —
Darin, is there anything that I can get the nordstrom people to change on their server to allow peole to use this site?
I have yet to analyze barrowman's HTTP log... i plan to get to it sometime before the end of the week. let me know if that's not going to be soon enough.
Attached file http log segment (deleted) —
the log segment that i just attached (not from barrowman's log) shows that the nordstrom server seems to be doing something a little strange. first, it seems that it is responding with 100 Continue followed by an EMPTY 200 OK header. i don't quite understand why they would be sending an empty 200 OK header. that packet contains some data... i'm going to run a packet sniffer now to see what the data looks like. basically, the problem seems to be that we're getting into a state in which we are expecting the server to close the connection when it has sent all of the data (since this is the default behavior, and the default behavior applies when there are no other headers to change the behavior).
ok, here's what the packet trace looks like: T 64.130.71.9:33640 -> 65.203.228.90:80 [AP] POST /checkout/shoppingbag.asp HTTP/1.1..Host: secure.nordstrom.com..U ser-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5+) Gecko/20 011026..Accept: text/xml, application/xml, application/xhtml+xml, text /html;q=0.9, image/png, image/jpeg, image/gif;q=0.2, text/plain;q=0.8, text/css, */*;q=0.1..Accept-Language: en-us..Accept-Encoding: gzip, d eflate, compress;q=0.9..Accept-Charset: ISO-8859-1, utf-8;q=0.66, *;q= 0.66..Keep-Alive: 300..Connection: keep-alive..Cookie: nordstrom=BAGCO UNT=1&SHOPPERID=A5476EWC4RQG8PDCM0AAR0RHW6NDE29E..Referer: http://secu re.nordstrom.com/checkout/shoppingbag.asp?URL=http%3A%2F%2Fstore%2Enor dstrom%2Ecom%2Fproduct%2Fproduct%2Easp%3Fstyleid%3D2786682%26category% 3D2376778%7E2372807%7E2372817%7E2375558%26PrevStyleID%3Dnone%26NextSty leID%3D2784430.. ## T 64.130.71.9:33640 -> 65.203.228.90:80 [AP] Content-type: application/x-www-form-urlencoded..Content-Length: 147.. ..button=update&stritem=&item=8604129&FulfillmentMethod=&addressid=&qt y_1=1&macscategory_1=EJ8&itemnum_1=S04712+200+7+D&itemprice_1=99.95&It emTotal=1 # T 65.203.228.90:80 -> 64.130.71.9:33640 [AP] HTTP/1.1 100 Continue..Server: Microsoft-IIS/5.0..Date: Fri, 26 Oct 20 01 16:49:04 GMT..Pragma: No-cache..Cache-control: No-cache..Set-Cookie : SessionUUID=60262ebc-c3b3-493b-b64e-0d2762642c79; path=/; domain=nor dstrom.com.... ## T 65.203.228.90:80 -> 64.130.71.9:33640 [AP] HTTP/1.1 200 Ok....<head><title>Object moved</title></head>.<body><h1> Object Moved</h1>This object may be found <a HREF="https://secure.nord strom.com/checkout/signin.asp">here</a>.</body>. notice, that this looks like the server wants to redirect the client to the signin page. however, if this is it's intent then it is sending the wrong HTTP response code. it should be sending 302 or one of the other redirect codes to indicate that this is a redirection. so, looks like this bug is entirely a problem with the nordstrom server.
one other interesting thing to note, is that i don't believe that we would pick up the Set-Cookie header given in the 100 Continue response. on this note, the HTTP/1.1 spec, section 10.1.1, says: 100 Continue The client should continue with its request. This interim response is used to inform the client that the initial part of the request has been received and has not yet been rejected by the server. The client should continue by sending the remainder of the request or, IF THE REQUEST HAS ALREADY BEEN COMPLETED, IGNORE THE RESPONSE. The server must send a final response after the request has been completed. The uppercase phrase applies to us. We send the complete request along with the POST request. We are therefore permitted to ignore the 100 Continue message, and I think we are therefore permitted to ignore the Set-Cookie header. Therefore, I think the server should not be sending a Set-Cookie header along with a 100 Continue and expect clients to do anything meaningful with it.
to evangelism.
Assignee: darin → nitot
Status: ASSIGNED → NEW
Component: Networking: HTTP → African
Product: Browser → Tech Evangelism
QA Contact: tever → momoi
Version: other → unspecified
Component -> English:US
Assignee: nitot → bclary
Component: African → English: US
QA Contact: momoi → zach
Removing topembed. Thanks Darin.
Keywords: topembed
-> marcio
Assignee: bclary → mgalli
Accepting.
Status: NEW → ASSIGNED
CANNOT CHECK OUT IN: 2002-03-14-03 Win2K CAN CHECK OUT IN: 2002-03-15-03 Win2K It is essential to find out what fixed this site and get it embedded. Added nsbeta1, topembed Verified works in Mozilla builds: 2002-03-22 2002-03-19-03 2002-03-16-08 Seems to work in all subsequent mozilla builds. (Note: to test properly if you can get to Shipping Destination page, it's working) Changed category to Browser instead of Evangelism. I'm guessing HTTP as the category since hanging occurs on a secure server. Related: http://bugscape.netscape.com/show_bug.cgi?id=7320
Assignee: mgalli → darin
Severity: normal → major
Status: ASSIGNED → NEW
Component: US General → Networking: HTTP
Keywords: nsbeta1, topembed
Product: Tech Evangelism → Browser
QA Contact: zach → tever
Whiteboard: topsite, partner
Target Milestone: Nov → M1
Version: unspecified → other
susie: i'm confused. when i investigated this previously, i found that the server was misbehaving. that's why i reassigned this one to evangelism. i'm surprised that this particular site would work at all in any browser without some serious workarounds on the client side. i'll take another look at this site to see if it's behavior has changed since i last looked.
now, when i follow dave's steps in comment #15, i get the following packet trace: T 10.169.106.21:34546 -> 65.203.228.155:80 [AP] POST /checkout/shoppingbag.asp HTTP/1.1..Host: secure.nordstrom.com..User-A gent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9+) Gecko/20020404..Ac cept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/p lain;q=0.8,video/x-mng,image/png,image/jpeg,image/gif;q=0.2,text/css,*/*;q= 0.1..Accept-Language: en-us, en;q=0.50..Accept-Encoding: gzip, deflate, com press;q=0.9..Accept-Charset: ISO-8859-1, utf-8;q=0.66, *;q=0.66..Keep-Alive : 300..Connection: keep-alive..Referer: http://secure.nordstrom.com/checkou t/shoppingbag.asp?URL=http%3A%2F%2Fstore%2Enordstrom%2Ecom%2Fproduct%2Fprod uct%5Fbrandboutique%2Easp%3Fstyleid%3D2786682%26boutique%3Dfitness%5Fshop%5 Fmen%26category%3D2376778%7E2372807%7E2372817%7E2375558%26NextStyleID%3D278 4430%26PrevStyleID%3Dnone..Cookie: nordtrial=TRANSFERREDREQUEST=False&TESTC USTOMER=True; nordstrom=BAGCOUNT=1&SHOPPERID=11QV31ASSTE39KB58CBLFV9GM7P1EH 5E&FIRSTNAME=; SessionUUID=e68c6c1d-e03b-4233-aae2-79da8fcacc73; SITESERVER =ID=b81af245c77c564db0134d1021283e91.. ## T 10.169.106.21:34546 -> 65.203.228.155:80 [AP] Content-Type: application/x-www-form-urlencoded..Content-Length: 149....but ton=update&stritem=&item=11536779&FulfillmentMethod=&addressid=&qty_1=1&mac scategory_1=EJ8&itemnum_1=S04712+200+9+2E&itemprice_1=99.95&ItemTotal=1 # T 65.203.228.155:80 -> 10.169.106.21:34546 [AP] HTTP/1.1 100 Continue..Server: Microsoft-IIS/5.0..Date: Fri, 05 Apr 2002 17 :16:07 GMT..Pragma: No-cache..Cache-control: No-cache..P3P: CP="ALL DSP CUR a IVAa HISa OUR NOR IND UNI NAV INT STA PRE".... ## T 65.203.228.155:80 -> 10.169.106.21:34546 [A] HTTP/1.1 302 Object moved..Server: Microsoft-IIS/5.0..Date: Fri, 05 Apr 200 2 17:16:07 GMT..Pragma: No-cache..Cache-control: No-cache..P3P: CP="ALL DSP CURa IVAa HISa OUR NOR IND UNI NAV INT STA PRE"..Location: https://secure. nordstrom.com/checkout/signin.asp..Content-Length: 169..Content-Type: text/ html..Expires: Fri, 05 Apr 2002 17:15:07 GMT..Cache-control: private....<he ad><title>Object moved</title></head>.<body><h1>Object Moved</h1>This objec t may be found <a HREF="https://secure.nordstrom.com/checkout/signin.asp"> ## T 65.203.228.155:80 -> 10.169.106.21:34546 [AP] here</a>.</body>. notice that the website appears to have fixed it's problem. the last response from the server in this packet trace is a 302 instead of a 200 as it was previously. marking WORKSFORME susie: IMO this bug was entirely server side.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
*** Bug 118355 has been marked as a duplicate of this bug. ***
reopening, for now. Darin, if this was a site fix wouldn't the checkout work in every build? refer to http://bugscape.netscape.com/show_bug.cgi?id=7320 for full details.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Target Milestone: M1 → mozilla1.0
ok, i'll try the 2002-03-14-03 Win2K build and try to see why it is failing.
changed summary
OS: Windows 98 → All
Summary: Mozilla receives different page after submiting this form. (HTTPS). → Nordstrom.com - hangs at checkout - Mozilla receives different page after submiting this form. (HTTPS).
susie: this is very odd. when i use can older browser (2002-03-11) under win2k, ic the server sending the malformed response. however, when i use a newer browser, the server sends the correct response. could the server be doing some useragent sniffing and getting it wrong? this is extremely wierd!
OS: All → Windows 98
Summary: Nordstrom.com - hangs at checkout - Mozilla receives different page after submiting this form. (HTTPS). → Mozilla receives different page after submiting this form. (HTTPS).
WFM if I use build 2002032803 but change the UA string to an older version -- Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.7+) Gecko/20020111 Does that eliminate that possibility that it's a sniffing issue?
yeah, definitely. i'm going to generate packet traces with each version of the browser and compare the bytes... hopefully that'll reveal something ;-)
i used bonsai to lookup the changes that occured between the two builds susie quoted... one or more of these changes must have fixed this, but i'm not sure which one it might be. there's nothing obvious as far as i can tell. http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=SeaMonkeyAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=03%2F13%2F2002&maxdate=03%2F15%2F2002&cvsroot=%2Fcvsroot
Keywords: nsbeta1 → nsbeta1+
Whiteboard: topsite, partner → topsite, partner, [adt2]
OS: Windows 98 → All
Finished moving info from bug 118355.
plusing to topembed+ as per edt meeting since nordstrom is one of our topsites and partner.
Keywords: topembed → topembed+
marking FIXED since this bug does not exist on the trunk or on the mozilla 1.0 branch.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
this is working for me too using recent builds verified 04/25/02 trunk builds - winNT4, linux rh6, mac osX
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: