Closed Bug 111960 Opened 23 years ago Closed 23 years ago

should ignore newline character in Set-Cookie header

Categories

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

Product:
Core
Component:
Networking: HTTP
Platform:
Other
FreeBSD
Type:
defect

Tracking

()

Status:
VERIFIED WONTFIX
Milestone:
mozilla0.9.9

People

(Reporter: dloose84, Assigned: badami)

References

(
URL
)

Details

(Whiteboard: [patch needs r/sr=])

Attachments

(5 files)

example of bug on ODU system
136.41 KB, application/octet-stream
Details
Log file of interaction between Mozilla and Server
12.30 KB, application/octet-stream
Details
remove \n in headers
1.76 KB, patch
Details | Diff | Splinter Review
as Darin's comments
760 bytes, patch
morse
: review+
darin.moz
: superreview+
Details | Diff | Splinter Review
cgi used for testing
895 bytes, text/plain
Details 
I've had this problem since I started using mozilla with M18.  Whenever I try to
login to my school's registration page, it prints the following data at the top
of the page and sends me back to the login page:

0 HTTP/1.1 200 OK Transfer-Encoding: chunked Date: Mon, 26 Nov 2001 16:42:20 GMT
Allow: GET, HEAD Server: Oracle_Web_Listener/4.0.8.2.1EnterpriseEdition
Content-Type: text/html Set-Cookie: SESSID=; expires=Monday, 01-Jan-1990
08:00:00 GMT; Content-length: 3160 Connection: Keep-Alive Keep-Alive:
timeout=10, max=999 c58

This data is printed in Windows 98 using .9.6 but the login process proceeds
anyway.  This is reproducible at http://registrar.wpi.edu but a valid account is
needed to see the error.  I have not seen it anywhere else.

A screenshot of the error is at http://www.wpi.edu/~dloose/moz-error.jpg
Dave: Do you see those http-header information with any other browser as well?

Can you fire up this page and see if it prints the header?
--> http://jigsaw.w3.org/HTTP/ChunkedScript

And: The machine seems to be a win2k box -- is there any chance you find out
what version they use? (os, os-patchlevel, iis)
Reporter: Is the font with which the http-header is rendered
your default font? If not, maybe the Oracle application is to blame?

reporter: are you connecting via a proxy server?
I don't see the header information with other browsers, but I haven't yet found
a browser that will log me in.  I've tried Opera, Konqueror, Galeon, and maybe a
few others.  I'm running FreeBSD 4.4, by the way.

I don't connect via a proxy server and no one has responded to me yet so I don't
know what version of Win2k they're running.

I tried this bug report as a last resort of sorts.  Nobody else has been able to
help me, so I was hoping that maybe it was a mozilla problem.
reporter: can you generate a network packet trace using a tool such as
ngrep.sourceforge.net?  if so, that would greatly help in determining what could
be going wrong here.  thx!
This is a postscript file which shows what the page looks like with the exposed
header files.
I've added an attachment to this bug as it seems that we're experiencing the
same issue. Here's a report from our systems admin who is experiencing the
problem (he's tried to create a bugzilla account but he's been unsuccessful so
he asked me to submit one):

While logging attempting to login into a server (Oracle_Web_Listener/4.0.8.1.0 
EnterpriseEdition) via ssl (port 443) using cookie based authentication, after 
entering a valid User-id and Pin and clicking "Login" you are returned to the
login page with the following at the top of Login page:

 0 HTTP/1.1 200 OK Transfer-Encoding: chunked Date: Wed, 23 Jan 2002 20:10:02 
 GMT Allow: GET, HEAD Server: Oracle_Web_Listener/4.0.8.1.0EnterpriseEdition 
 Content-Type: text/html Set-Cookie: SESSID=; expires=Monday, 01-Jan-1990 
 08:00:00 GMT; Content-length: 3783 Connection: Keep-Alive Keep-Alive: 
 timeout=10, max=999 ec7

I've received this problem using Mozilla 0.9.6 on Solaris 8, Mozilla 0.9.2 on 
Linux (RH 7.2 Kernel 2.4.16), Mozilla 0.9.7 on Linux (RH 7.2 Kernel 2.4.16).

It would appear that Mozilla is treating the cookie as HTML instead of a 
cookie being sent as part of the header information.  

I've tried logging into this site using Netscape v4.78 for Linux (RH 7.2 Kernel
2.4.16) and in Windows 2000 using IE5 with success.

I've also attached a PostScript file of a print out of the exact behavior of 
returned after entering User-ID, Pin and clicking "Login".

reporter: can you confirm the problem using a more recent nightly build?
We just pulled down the latest Linux build (2002012308) and now it's doing
something different... it's not showing the data on top of the page anymore, but
it doesn't appear to be processing the cookie data correctly.

Since this page uses SSL, we're creating a SSL dumper to dump the interaction
between server and browser to see what's going on... once we generate a dump,
would you find a copy of this dump useful?
yes, but what would be even more useful to me would be a HTTP log.  you can set
the following environment variables to cause mozilla to dump information about
what our HTTP code is doing:

  setenv NSPR_LOG_MODULES nsHttp:5
  setenv NSPR_LOG_FILE http.log

please attach the "http.log" file to this bug.  thx!
Daren, attached is the log you requested. We were looking at it, and around
line 1907 it gets interesting. Between that line and line 2092, the pin is
entered and the user is flipped back to the login prompt instead of proceeding
thru the screens.
Was wondering if a solution to this bug has been found.  Noticed while looking
through the http.log that there seems to be a 'LF' after the Set-Cookie between
lines 1314-1315.  I don't know if this is from the Mozilla debugging log code if
it this is the actuall header sent back, but could this be the issue?  Here's a
dump of what I'm refering including Hex:

Snippet of Oracle response to Mozilla: (lines 1309 - 1319)

1026[810c0a0]: http response [
1026[810c0a0]:   HTTP/1.1 200 OK
1026[810c0a0]:   Transfer-Encoding: chunked
1026[810c0a0]:   Date: Thu, 24 Jan 2002 13:32:47 GMT
1026[810c0a0]:   Allow: GET, HEAD
1026[810c0a0]:   Server: Oracle_Web_Listener/4.0.8.1.0EnterpriseEdition
1026[810c0a0]:   Content-Type: text/html
1026[810c0a0]:   Set-Cookie: TESTID=set;
SESSID=; expires=Monday, 01-Jan-1990 08:00:00 GMT;
1026[810c0a0]:   Content-Length: 3783
1026[810c0a0]:   Connection: Keep-Alive
1026[810c0a0]:   Keep-Alive: timeout=10, max=999
1026[810c0a0]: ]


Hex Dump of Oracle response to Mozilla: (lines 1309 - 1319)

00014DD0  20 68 74 74  70 20 72 65   73 70 6F 6E  73 65 20 5B    http response [
00014DE0  0A 31 30 32  36 5B 38 31   30 63 30 61  30 5D 3A 20   .1026[810c0a0]: 
00014DF0  20 20 48 54  54 50 2F 31   2E 31 20 32  30 30 20 4F     HTTP/1.1 200 O
00014E00  4B 0A 31 30  32 36 5B 38   31 30 63 30  61 30 5D 3A   K.1026[810c0a0]:
00014E10  20 20 20 54  72 61 6E 73   66 65 72 2D  45 6E 63 6F      Transfer-Enco
00014E20  64 69 6E 67  3A 20 63 68   75 6E 6B 65  64 0A 31 30   ding: chunked.10
00014E30  32 36 5B 38  31 30 63 30   61 30 5D 3A  20 20 20 44   26[810c0a0]:   D
00014E40  61 74 65 3A  20 54 68 75   2C 20 32 34  20 4A 61 6E   ate: Thu, 24 Jan
00014E50  20 32 30 30  32 20 31 33   3A 33 32 3A  34 37 20 47    2002 13:32:47 G
00014E60  4D 54 0A 31  30 32 36 5B   38 31 30 63  30 61 30 5D   MT.1026[810c0a0]
00014E70  3A 20 20 20  41 6C 6C 6F   77 3A 20 47  45 54 2C 20   :   Allow: GET, 
00014E80  48 45 41 44  0A 31 30 32   36 5B 38 31  30 63 30 61   HEAD.1026[810c0a
00014E90  30 5D 3A 20  20 20 53 65   72 76 65 72  3A 20 4F 72   0]:   Server: Or
00014EA0  61 63 6C 65  5F 57 65 62   5F 4C 69 73  74 65 6E 65   acle_Web_Listene
00014EB0  72 2F 34 2E  30 2E 38 2E   31 2E 30 45  6E 74 65 72   r/4.0.8.1.0Enter
00014EC0  70 72 69 73  65 45 64 69   74 69 6F 6E  0A 31 30 32   priseEdition.102
00014ED0  36 5B 38 31  30 63 30 61   30 5D 3A 20  20 20 43 6F   6[810c0a0]:   Co
00014EE0  6E 74 65 6E  74 2D 54 79   70 65 3A 20  74 65 78 74   ntent-Type: text
00014EF0  2F 68 74 6D  6C 0A 31 30   32 36 5B 38  31 30 63 30   /html.1026[810c0
00014F00  61 30 5D 3A  20 20 20 53   65 74 2D 43  6F 6F 6B 69   a0]:   Set-Cooki
00014F10  65 3A 20 54  45 53 54 49   44 3D 73 65  74 3B 0A 53   e: TESTID=set;.S
00014F20  45 53 53 49  44 3D 3B 20   65 78 70 69  72 65 73 3D   ESSID=; expires=
00014F30  4D 6F 6E 64  61 79 2C 20   30 31 2D 4A  61 6E 2D 31   Monday, 01-Jan-1
00014F40  39 39 30 20  30 38 3A 30   30 3A 30 30  20 47 4D 54   990 08:00:00 GMT
00014F50  3B 0A 31 30  32 36 5B 38   31 30 63 30  61 30 5D 3A   ;.1026[810c0a0]:
00014F60  20 20 20 43  6F 6E 74 65   6E 74 2D 4C  65 6E 67 74      Content-Lengt
00014F70  68 3A 20 33  37 38 33 0A   31 30 32 36  5B 38 31 30   h: 3783.1026[810
00014F80  63 30 61 30  5D 3A 20 20   20 43 6F 6E  6E 65 63 74   c0a0]:   Connect
00014F90  69 6F 6E 3A  20 4B 65 65   70 2D 41 6C  69 76 65 0A   ion: Keep-Alive.
00014FA0  31 30 32 36  5B 38 31 30   63 30 61 30  5D 3A 20 20   1026[810c0a0]:  
00014FB0  20 4B 65 65  70 2D 41 6C   69 76 65 3A  20 74 69 6D    Keep-Alive: tim
00014FC0  65 6F 75 74  3D 31 30 2C   20 6D 61 78  3D 39 39 39   eout=10, max=999
00014FD0  0A 31 30 32  36 5B 38 31   30 63 30 61  30 5D 3A 20   .1026[810c0a0]: 
00014FE0  5D 0A 31 30  32 36 5B 38   31 30 63 30  61 30 5D 3A   ].1026[810c0a0]:

-Adam
cc'ing morse, owner of the mozilla cookies module.  

morse: this server is sending a Set-Cookie header w/ an embedded newline.  seems
mozilla is failing to treat the newline as ordinary whitespace.  you think we
should bother fixing this one?  my feeling is that this should be an evangelism
bug purely because allowing embedded newlines like this may interfere with
future developments of the HTTP protocol.  that is, we probably shouldn't
support this bad-form.  what do you think?
What does the http spec say about embedded newlines in headers?  Seems to me 
that if other browsers (notably IE) accepts it, then we probably should too.

I've seen many similar bug reports in the past describing this same symptom.  So 
I don't think this is the only site affected.  If we can come up with a fix for 
it, I think we should.
Reading through the RFC for HTTP 1.0 and HTTP 1.1 it states that New lines are
NOT allowed in the HTTP Header.  Though Browsers such as Netscape 4.78 and IE5
do NOT have trouble with this embedded newline.

-Adam

the http code could easily replace the newline with a space character and then
compact whitespace, but we can't guarantee that mozilla will always support this
broken behavior. is this just a misconfiguration of oracle?
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Priority: -- → P3
Target Milestone: --- → mozilla0.9.9
My recommendation is to convert the newlines to spaces, especially since IE 
seems to be doing that.  Many sites seem to have this error since I've seen this 
happen many times.  It's easier to handle it than it is to find all these sites 
and then evangelize them.
morse: agreed... modifying summary... reassigning to vinay
Assignee: darin → badami
Status: ASSIGNED → NEW
Summary: HTTP header data displayed at top of page → should ignore newline character in Set-Cookie header
Is set-cookie header the only header that potentially has this problem?
morse: the thing is the HTTP spec allows embedded newlines in headers, but the
next line is supposed to be indented with whitespace.  also, if all of the
headers ended with LF (instead of CRLF) we'd have a problem because we wouldn't
be able to determine if this line was a continuation or another header
altogether.  so, we have to be careful.  in this case all of the headers end
with CRLF so we can discern the continuation.  we should do this for all
headers... it probably involves fixing code in nsHttpHeaderArray::SetHeader.
Think we should do the same with \r ???
vinay: i thought about this some more, and i'm starting to think that it would
be best to actually remove the '\n' and '\r' characters instead of simply
overwriting each with a space.  content providers probably never meant to inject
the newline char(s).

so, how about this instead:

  nsCAutoString buf;
  if (strpbrk(value, "\r\n")) {
      buf.Assign(value);
      buf.StripChars("\r\n");
      value = buf.get();
  }

Darin
Let us go with what u r proposing. Since we do not have a reproducible test
case, if this comes back as a reopen, we can then look at just replacing the
\r\n with spaces.
Keywords: patch
Whiteboard: [patch needs r/sr=]
Comment on attachment 69223 [details] [diff] [review]
as Darin's comments

r=morse
Attachment #69223 - Flags: review+
I can be your test case if you want.  I have a valid account with this product,
SCT/Oracle Application with the 'LF' between set-cookies.

-Adam

Fixed!!  I would like to thank the Mozilla team for the quick response and fix
for the Big co's screwups.  THANK YOU..

-Adam

Comment on attachment 69223 [details] [diff] [review]
as Darin's comments

sr=darin

vinay: thx for writing up this patch!
Attachment #69223 - Flags: superreview+
Adam
Are u saying that this now works ? The fix for the problem is not yet checked in. 
Can u be a bit more specific about comment 26.

Vinay,

Yes... After putting that comment in and re-reading the dialog, I realized that
you hadn't patched the main cvs branch, that Joe Smoe get's the source from. 
Under Linux 2.4.16, Stock RH7.2 libs, compiled the cvs checked out source,
compiled, and ran mozilla against the SCT/OAS that was causing issues with
cookies being displayed as HTML in the browser.  It worked, I was able to enter
user-id, password (as before) and this time when I clicked login, I actually was
logged in, no cooki information dumped to the screen.  Tested this login in and
out, and moving around, with no problems. 

Then realized that the patch that has been floating around was a diff from your
local copy verse the cvs repository.  So I sucked down the two patches - 'remove
\n in headers' (applied), then - 'as Darin's comments' (applied) and recompiled.
I received the same behaviour as before the patch(es) were installed, but after
I downloaded the source via cvs and compiled it.  It worked.

I've checked with the Dept that maintains the SCT/OSA app and they have made NO
changes since I appended to this bug.

Leads me to wonder, if perhaps 'LF' isn't the problem?  Or wasn't completely the
problem?  If you needs http.log or any other information please let me know.

-Adam
Attached file cgi used for testing — 
Wrote a env.c cgi that echoes the env back.Also sets a cookie with a name=value
and the value having a \n in it.
Compiled it and deployed it on a apache as a nph-cgi so that apache does not
barf about the \n in the cookie header.
Tested it on IE/Nav4.7/Mozilla.
First request we get no cookie.
Second request we get a cookie back with value being only line1 and not
containing line2.
All browsers behave similarly.
Based on this suggesting that we do not try patching this.
I would suggest not patching this until someone comes up with a test case that
demonstrates that IE/Moz behave differently on Cookies with \n embedded in the
value.

vinay: does endl correspond to CRLF or LF?  if it corresponds to LF then you are
testing the wrong thing.  we need to test what happens when we send headers that
end with CRLF and contain an embedded LF.  i'm guessing that your CGI was run on
a linux box and therefore generates LF after each header instead of CRLF. 
please confirm.  a network trace might be the best way to determine what's
really going on.  thx!
endl results in a CRLF.
Tested and verified this with a network trace.
vinay: ok, interesting.

morse: see comment #30 and #31... what do you think?  should we leave this be?
I would agree.  If all browsers behave the same way, then we shouldn't try to be 
different.  Who knows what site we'll break if we do.
MArking as WONTFIX based on findings and comments 34 35.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WONTFIX
V/wontfix.
Status: RESOLVED → VERIFIED
QA Contact: tever → benc
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: