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

VERIFIED FIXED in mozilla1.0

Status

()

defect
P1
major
VERIFIED FIXED
18 years ago
17 years ago

People

(Reporter: mgalli, Assigned: darin.moz)

Tracking

({topembed+})

Trunk
mozilla1.0
x86
All
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: topsite, partner, [adt2], )

Attachments

(2 attachments)

Reporter

Description

18 years ago
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.
Reporter

Comment 1

18 years ago
Adding roger,.. do you have the same problem here?

Comment 2

18 years ago
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...
Reporter

Comment 3

18 years ago
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. 
Reporter

Comment 4

18 years ago
Setting topembed. 
Keywords: topembed

Comment 5

18 years ago
cc'ing folks. does this look content or client related?

Comment 6

18 years ago
is this a recent regression?
Assignee

Comment 7

18 years ago
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

Comment 8

18 years ago
Darin - I'd be happy to provide an HTTP log - is there a way to enable logging
for Win98?

Comment 9

18 years ago
Jud - I don't think this is a recent regression - I get the same behavior on
N6.1 / Win98.

Updated

18 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee

Comment 10

18 years ago
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

Comment 11

18 years ago
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.
Assignee

Comment 12

18 years ago
dave: the logging feature was not present in NS6.1, can you please try a recent
nightly build.  thx!

Comment 13

18 years ago
->darin
Assignee: neeti → darin
Assignee

Comment 14

18 years ago
-> 0.9.6
Status: NEW → ASSIGNED
Priority: -- → P1
Target Milestone: --- → mozilla0.9.6

Updated

18 years ago
Blocks: 64833

Comment 15

18 years ago
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.

Comment 17

18 years ago
Darin, is there anything that I can get the nordstrom people to change on their
server to allow peole to use this site? 
Assignee

Comment 18

18 years ago
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.
Assignee

Comment 19

18 years ago
Posted file http log segment
Assignee

Comment 20

18 years ago
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).
Assignee

Comment 21

18 years ago
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.
Assignee

Comment 22

18 years ago
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.
Assignee

Comment 23

18 years ago
to evangelism.
Assignee: darin → nitot
Status: ASSIGNED → NEW
Component: Networking: HTTP → African
Product: Browser → Tech Evangelism
QA Contact: tever → momoi
Version: other → unspecified
Assignee

Comment 24

18 years ago
Component -> English:US
Assignee: nitot → bclary
Component: African → English: US
QA Contact: momoi → zach
Reporter

Comment 25

18 years ago
Removing topembed. Thanks Darin.
Keywords: topembed

Comment 26

18 years ago
-> marcio
Assignee: bclary → mgalli
Reporter

Comment 27

18 years ago
Accepting.
Status: NEW → ASSIGNED

Comment 28

18 years ago
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
Assignee

Comment 29

18 years ago
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.
Assignee

Comment 30

18 years ago
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: 18 years ago
Resolution: --- → WORKSFORME

Comment 31

18 years ago
*** Bug 118355 has been marked as a duplicate of this bug. ***

Comment 32

18 years ago
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
Assignee

Comment 33

18 years ago
ok, i'll try the 2002-03-14-03 Win2K build and try to see why it is failing.

Comment 34

18 years ago
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).
Assignee

Comment 35

18 years ago
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).

Comment 36

18 years ago
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?
Assignee

Comment 37

18 years ago
yeah, definitely.  i'm going to generate packet traces with each version of the
browser and compare the bytes... hopefully that'll reveal something ;-)
Assignee

Comment 38

18 years ago
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

Updated

18 years ago
Keywords: nsbeta1nsbeta1+
Whiteboard: topsite, partner → topsite, partner, [adt2]

Updated

18 years ago
OS: Windows 98 → All

Comment 39

18 years ago
Finished moving info from bug 118355.

Comment 40

18 years ago
plusing to topembed+ as per edt meeting since nordstrom is one of our topsites
and partner.
Keywords: topembedtopembed+
Assignee

Comment 41

17 years ago
marking FIXED since this bug does not exist on the trunk or on the mozilla 1.0
branch.
Status: REOPENED → RESOLVED
Closed: 18 years ago17 years ago
Resolution: --- → FIXED

Comment 42

17 years ago
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.