Possible problem in the HttpMessage class

Description

We are using mirror frames to proxy a websphere server.  Our problem is
as followings: WebSphere would send back 2 Set-Cookie headers, one is
the LptaToken (which is quite long) and the second is JSESSIONID.  When
jigsaw was done proxying the request those 2 headers which were combined
into one Set-Cookie header with the 2 cookie values separated by a
comma.  I think this is considered to be o.k. from the HTTP protocol
standpoint, but both IE 6.0 and Netscape 4.7 didn't like it.  Both
browsers would acknowledge that the cookie had been received but they
would not send it back in subsequent requests.  I know they acknowledged
or read the cookie because we had turned on prompting for all cookies.

 

Problem resolution

In doing some hunting through the code we found that the 2 headers were
being put together when the BasicValue.addBytes method was being called.
I think that is o.k. from a general standpoint, but in our case what we
found was that the code kept hitting the "uglies hack I have ever wrote"
section.  This can be found in the emitHeaders(OutputStream out, int
what) method of  the HttpMessage class.

 

      // Emit well-known headers first:

      for (int i = 0 ; i < MAX_HEADERS ; i++) 

      {

          HeaderDescription d = descriptors[i];

          HeaderValue       v = values[i];

          if (v instanceof HttpSetCookieList) 

          {

                  // ugly hack :(

                  HttpSetCookieList hscl = (HttpSetCookieList) v;

                  int nbc = hscl.length();

                  if (nbc == 0) { //the ugliest hack I have ever wrote
;-)

                      out.write(d.getTitle());

                      out.write(':'); out.write(' ');

                      v.emit(out);

                      out.write('\r'); out.write('\n');

                  } 

                  else 

                  {

                      for (int j = 0 ; j < nbc ; j++) 

                      {

                              out.write(d.getTitle());

                              out.write(':'); out.write(' ');

                              hscl.emitCookie(out, j);

                              out.write('\r'); out.write('\n');

                      }

                  }

          } 

 

Our thought here is that the validate method should be called so that
the parse method of the HttpSetCookieList will get called.  When this
happens the nbc variable is properly populated and the logic goes to the
else statement which generates separate Set-Cookie headers and not the
"ugliest hack code" section.   Example code:

 

 

      // Emit well-known headers first:

      for (int i = 0 ; i < MAX_HEADERS ; i++) 

      {

          HeaderDescription d = descriptors[i];

          HeaderValue       v = values[i];

          if (v instanceof HttpSetCookieList) 

          {

                  // ugly hack :(

                  HttpSetCookieList hscl = (HttpSetCookieList) v;

                  // 11/24/2003 - Patch added by Brian Laird

                  // the validate method was added to fix the websphere
multiple cookie problem

                  hscl.validate();

                  int nbc = hscl.length();

                  if (nbc == 0) { //the ugliest hack I have ever wrote
;-)

                      out.write(d.getTitle());

                      out.write(':'); out.write(' ');

                      v.emit(out);

                      out.write('\r'); out.write('\n');

                  } 

                  else 

                  {

                      for (int j = 0 ; j < nbc ; j++) 

                      {

                              out.write(d.getTitle());

                              out.write(':'); out.write(' ');

                              hscl.emitCookie(out, j);

                              out.write('\r'); out.write('\n');

                      }

                  }

          } 

 

 

This fixes our problem, but I am not sure if it makes sense to call
validate on all of the values before emitting them or not.  Can you
confirm that our fix is both correct according to the HTTP spec and that
our fix or something like it should be done to jigsaw?  If you agree
with all this can you send me an email when you might have the fix done
and into the night build section?

 

O.k. so this ended up longer than I thought but thanks for the help and
please let me know if you need any more information.

 

Brian

************************************************************************
This e-mail and any accompanying documents or files contain information that is the 
property of Perseco, that is intended solely for those to whom this e-mail is addressed 
(i.e., those identified in the "To" and "Cc" boxes), and that is confidential, proprietary, 
and/or privileged.  If you are not an intended recipient of this e-mail, you are hereby 
notified that any viewing, use, disclosure, forwarding, copying, or distribution of any of 
this information is strictly prohibited and may be subject to legal sanctions.  If you have 
received this e-mail in error, please notify the sender immediately of any unintended 
recipients, and delete the e-mail, all attachments, and all copies of both from your system.

While we have taken reasonable precautions to ensure that any attachments to this e-mail 
have been swept for viruses, we cannot accept liability for any damage sustained as a 
result of software viruses.
************************************************************************