Closed Bug 101666 Opened 23 years ago Closed 22 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
473.71 KB, text/plain
Details
http log segment
7.27 KB, 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.


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 — 

    
    

    
  
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: 22 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: 22 years ago → 22 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: