WebResponse Headers comma delimiting mistake

  • Thread starter Thread starter Afanasiy
  • Start date Start date
A

Afanasiy

The expires date in a Set-Cookie header includes a comma in every
implementation I have seen or read documentation for. However, the CLR's
WebResponse Headers collection delimits headers of the same name with
commas. I thought I would get around this with the Headers collection
method GetValues("Set- Cookie"), but even at that point the headers have
already been corrupted by storage as a comma delimited string.

Is there a way around this with the CLR?

Basically, the WebResponse Header methods Get and GetValues are bugged
because they use a comma delimited string to store the headers.

I assume somewhere the real headers are available, but probably
not available in public. I assume this problem was allowed to occur
in the name of code reusability by way of the NameValueCollection.

Where can I report this bug?

Does anyone know of a workaround or a way to access the headers in
their raw line delimited form?

Is the CLR source available for perusing?

-AB
 
Can you clarify what problem you are seeing ? Are you saying that :

a) The header values (for the same header name) are comma delimited ? for
eg, if I do:

headers.Add("foo", "bar1");
headers.Add("foo", "bar2");

you get "foo: bar1,bar2" ?

If so, this is per the RFC.

b) Are you saying that the date value in the Set-Cookie header's expires
value has commas ? If so that is also per RFC.

As per the HTTP RFC ( RFC2616 ) , these are the formats for date headers:

HTTP-date = rfc1123-date | rfc850-date | asctime-date
rfc1123-date = wkday "," SP date1 SP time SP "GMT"
rfc850-date = weekday "," SP date2 SP time SP "GMT"
asctime-date = wkday SP date3 SP time SP 4DIGIT


Maybe I am not understanding your question correctly. It would help if you
could include a code snippet, and the expected vs. actual behavior that you
are seeing.

feroze.

--
Remove "user" from the email address to reply to the author.

This posting is provided "AS IS" with no warranties, and confers no rights

Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
 
Can you clarify what problem you are seeing ? Are you saying that :
Click to expand...

You are confused about the bug I am trying to explain,
but you are on track. I will try to make it clear.
As per the HTTP RFC ( RFC2616 ) , these are the formats for date headers:

HTTP-date = rfc1123-date | rfc850-date | asctime-date
rfc1123-date = wkday "," SP date1 SP time SP "GMT"
rfc850-date = weekday "," SP date2 SP time SP "GMT"
asctime-date = wkday SP date3 SP time SP 4DIGIT
Click to expand...

Exactly the problem.

The HTTP header values can contain commas, "per the RFC".
That is excellent, spectacular and good. But the CLR is not.

The CLR, when accessing header values, deals with them by
storing all the headers in a comma delimited string.

As such, in the CLR, when you loop over headers or try
to retrieve headers, all is not well due to the fact that
one of the header values contains commas (per the RFC).

With code like this you will see the problem with header
values which contain commas.

foreach (string h in response.Headers.GetValues("Set-Cookie")) {
Response.Write(h+"<hr>");
}

This would print something like this :

MyThing=SID=3461507; expires=Tue
--------------------------------------------------------------------------------
20-Apr-2004 05:00:00 GMT; path=/
--------------------------------------------------------------------------------
ASPSESSIONIDCSDTTTRS=PHNNPNAACLGNNAEEGKMCPMPB; path=/

When it should, in fact, per the rfc, print something like this :

MyThing=SID=3461507; expires=Tue, 20-Apr-2004 05:00:00 GMT; path=/
--------------------------------------------------------------------------------
ASPSESSIONIDCSDTTTRS=PHNNPNAACLGNNAEEGKMCPMPB; path=/

Do you see now? The comma in the header value is confusing the CLR.

That is the problem. This CLR problem is what I call a bug.

As I stated before, this is probably because the raw headers
are already processed into the NameValueCollection erroneously.
Accessing the headers in a variety of ways shows a definite
problem, with Get, GetValues and even ToString IIRC.

P.S. Per the RFC, Per the RFC...
 
You are confused about the bug I am trying to explain,
but you are on track. I will try to make it clear.


Exactly the problem.

With code like this you will see the problem with header
values which contain commas.

foreach (string h in response.Headers.GetValues("Set-Cookie")) {
Response.Write(h+"<hr>");
}

This would print something like this :

MyThing=SID=3461507; expires=Tue
--------------------------------------------------------------------------------
20-Apr-2004 05:00:00 GMT; path=/
--------------------------------------------------------------------------------
ASPSESSIONIDCSDTTTRS=PHNNPNAACLGNNAEEGKMCPMPB; path=/

When it should, in fact, per the rfc, print something like this :

MyThing=SID=3461507; expires=Tue, 20-Apr-2004 05:00:00 GMT; path=/
Click to expand...

Where can I report this bug?

Is the CLR source available for perusing?

Does anyone know of a workaround or a way to access
the headers in their raw line delimited form?

-AB
 
Can you show me the input header string as well ? Also, what is the
type of the "response" object used in your code ?
foreach (string h in response.Headers.GetValues("Set-Cookie")) {
Response.Write(h+"<hr>");
}
Click to expand...

Is it of type System.Net.HttpWebResponse, or System.Web.HttpResponse ?
I need to know to find out where this behavior is occuring.

I will need these two pieces of information before we decide if this
is a bug.

feroze.
==================================
This posting is provided as is, without warranties, and confers no
rights.
 
Can you show me the input header string as well ?
Click to expand...

Server: Microsoft-IIS/5.0
Date: Mon, 26 Jan 2004 07:52:38 GMT
X-Powered-By: ASP.NET
P3P: CP="NOI ADM DEV PSAi COM NAV OUR OTR STP IND DEM"
Content-Length: 2628
Content-Type: text/html
Set-Cookie: SomethingOrOther=SID=3482742; expires=Sun, 25-Apr-2004
05:00:00 GMT; path=/,ASPSESSIONIDACTTBRRQ=HHFFHIAAPHFPHKDFGDPOPBLG; path=/
Cache-control: private

Of course, my usenet client has wrapped the Set-Cookie line.
I assume you will be able to figure that out.
Also, what is the
type of the "response" object used in your code ?
Click to expand...

System.Net.WebResponse, as returned by System.Net.WebRequest's GetResponse
Is it of type System.Net.HttpWebResponse, or System.Web.HttpResponse ?
I need to know to find out where this behavior is occuring.
System.Net.WebResponse

I will need these two pieces of information before we decide if this
is a bug.
Click to expand...

It has to be a bug. :p

-AB
 
Thanks for that info.

WebHeaderCollection() class is a generic API for managing headers. It does
not have any knowledge about what the Semantics/syntax of the particular
header values are. When it sees a header, it will try to use the RFC
semantics for parsing the header values (if you call GetValues()). It does
not know that this is a "Set-Cookie" header, and so it should be parsed
differently. You will run into the same problem if you try to call
GetValues() on some other headers (like WWW-Authenticate, Authorization
etc).

If you are really interested in parsing the Set-Cookie header yourself, you
should use GetValue() method, and then parse the resultant string (which
will be the entire header value) yourself.

I am curious as to why you are doing this though. Have you looked at the
System.Net.Cookie, System.Net.CookieContainer, and
System.Net.CookieCollection classes ? If you set a CookieContainer on your
webrequest, it will make sure to parse the resultant "set-cookie" response
headers, and also to send the cookies when you send subsequent requests to
the same server/domain. You can also enumerate the cookies, and get the
name/values, expiry and other stuff. So, it will do the parsing for you.


--
Remove "user" from the email address to reply to the author.

This posting is provided "AS IS" with no warranties, and confers no rights

Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
 
Thanks for that info.

WebHeaderCollection() class is a generic API for managing headers. It does
not have any knowledge about what the Semantics/syntax of the particular
header values are. When it sees a header, it will try to use the RFC
semantics for parsing the header values (if you call GetValues()). It does
not know that this is a "Set-Cookie" header, and so it should be parsed
differently. You will run into the same problem if you try to call
GetValues() on some other headers (like WWW-Authenticate, Authorization
etc).

If you are really interested in parsing the Set-Cookie header yourself, you
should use GetValue() method, and then parse the resultant string (which
will be the entire header value) yourself.

I am curious as to why you are doing this though. Have you looked at the
System.Net.Cookie, System.Net.CookieContainer, and
System.Net.CookieCollection classes ? If you set a CookieContainer on your
webrequest, it will make sure to parse the resultant "set-cookie" response
headers, and also to send the cookies when you send subsequent requests to
the same server/domain. You can also enumerate the cookies, and get the
name/values, expiry and other stuff. So, it will do the parsing for you.
Click to expand...

There is no CookieContainer in the WebRequest I am using.

There is in the System.Web.Services.Protocol stuff HttpWebClientProtocol,
etc, but those seem much less useful to me. They seem part of something
automated, something I cannot control. For example, I cannot call
GetWebResponse (the equivalent of GetResponse).

I am manually fetching web pages. The HttpWebClientProtocol classes
seem ill suited to this purpose as compared to the basic WebRequest.

Plus, the XML talk in their documentation is unconvincing.

I am doing nothing with XML. I am wrapping remotely GET'ed html.

-AB
 
Hi!

There are two types of classes. The System.Web.HttpRequest class is a
server side class, which represents the request sent by the client.
THe System.Net.HttpWebRequest represents a request a client can send
to a server. You should be clear which one you are using.

The Cookie/CookieContainer/CookieCollection classes are in System.Net
namespace.

You can look at the quickstart samples that ship with the framework
SDK to see how to use cookie functionality in System.Net.

feroze
 
Hi!

There are two types of classes. The System.Web.HttpRequest class is a
server side class, which represents the request sent by the client.
THe System.Net.HttpWebRequest represents a request a client can send
to a server. You should be clear which one you are using.

The Cookie/CookieContainer/CookieCollection classes are in System.Net
namespace.

You can look at the quickstart samples that ship with the framework
SDK to see how to use cookie functionality in System.Net.

feroze
Click to expand...

Ugh. Do you reply without the benefit of a threaded NNTP client?
 
Back
Top