I think the relevant section is 4.2 - and it says:
It MUST be possible to combine the multiple header fields into one
"field-name: field-value" pair, without changing the semantics of the
message, by appending each subsequent field-value to the first, each
separated by a comma.
So g
On Sunday 18 August 2002 11:02 am, [EMAIL PROTECTED] wrote:
> My understanding - the HTTP spec doesn't ( and can't ) define a complete
> list of headers supporting multiple values. That's impossible given that
> additional headers are supported.
>
The spec does exactly that. It enumerates the pro
My understanding - the HTTP spec doesn't ( and can't ) define a complete
list of headers supporting multiple values. That's impossible given that
additional headers are supported.
If the servlet spec requires getHeader() to return the 'concatenated value
for multi-headers' - then the spec can't b
Steve Downey wrote:
> On Sunday 18 August 2002 08:39 am, Remy Maucherat wrote:
>
>>Yes, it is right.
>>
>>Consider:
>>H: A, B
>>
>>In that case, getHeader() has to return "A, B" since it is not known if
>>this header is comma separated, as per the spec definition.
>>
>
>
> Ah. That's where we'r
On Sunday 18 August 2002 08:39 am, Remy Maucherat wrote:
> Steve Downey wrote:
> > On Saturday 17 August 2002 01:40 pm, Remy Maucherat wrote:
> >>Steve Downey wrote:
> >
> >
> >
> >>>The real problem, for the servlet spec implementation, is that not just
> >>>getHeaders() is affected. getHeader()
Steve Downey wrote:
> On Saturday 17 August 2002 01:40 pm, Remy Maucherat wrote:
>
>>Steve Downey wrote:
>
>
>
>>>The real problem, for the servlet spec implementation, is that not just
>>>getHeaders() is affected. getHeader() must be also. getHeader, if there
>>>are multiple values, needs to
On Saturday 17 August 2002 01:40 pm, Remy Maucherat wrote:
> Steve Downey wrote:
> >
> > The real problem, for the servlet spec implementation, is that not just
> > getHeaders() is affected. getHeader() must be also. getHeader, if there
> > are multiple values, needs to return the same thing as t
Steve Downey wrote:
> On Saturday 17 August 2002 12:47 pm, Remy Maucherat wrote:
>
>>Steve Downey wrote:
>>
>>>On Saturday 17 August 2002 09:00 am, Remy Maucherat wrote:
>>>
Patrick Luby wrote:
>Steve,
>
>Your assessment is correct: an aggregate header like:
>
> heade
On Saturday 17 August 2002 12:47 pm, Remy Maucherat wrote:
> Steve Downey wrote:
> > On Saturday 17 August 2002 09:00 am, Remy Maucherat wrote:
> >>Patrick Luby wrote:
> >>>Steve,
> >>>
> >>>Your assessment is correct: an aggregate header like:
> >>>
> >>> header1: val1, val2
> >>>
> >>>should be
On Saturday 17 August 2002 12:13 pm, Patrick Luby wrote:
> Remy,
>
> Remy Maucherat wrote:
> > No, this is not correct.
> >
> > You are allowed to do that only if the application knows it makes sense
> > to do so (ie, only when it call getHeaders).
> >
> > Some code to do that should be added in t
Steve Downey wrote:
> On Saturday 17 August 2002 09:00 am, Remy Maucherat wrote:
>
>>Patrick Luby wrote:
>>
>>>Steve,
>>>
>>>Your assessment is correct: an aggregate header like:
>>>
>>> header1: val1, val2
>>>
>>>should be converted to this for the HttpRequest:
>>>
>>> header1: val1
>>> heade
On Saturday 17 August 2002 09:00 am, Remy Maucherat wrote:
> Patrick Luby wrote:
> > Steve,
> >
> > Your assessment is correct: an aggregate header like:
> >
> > header1: val1, val2
> >
> > should be converted to this for the HttpRequest:
> >
> > header1: val1
> > header1: val2
>
> No, this
Patrick Luby wrote:
> Remy,
>
> Remy Maucherat wrote:
>
>>
>> No, this is not correct.
>>
>> You are allowed to do that only if the application knows it makes
>> sense to do so (ie, only when it call getHeaders).
>>
>> Some code to do that should be added in the adapter.
>
>
> This makes more
Remy,
Remy Maucherat wrote:
>
> No, this is not correct.
>
> You are allowed to do that only if the application knows it makes sense
> to do so (ie, only when it call getHeaders).
>
> Some code to do that should be added in the adapter.
This makes more sense than my original thoughts since t
Patrick Luby wrote:
> Steve,
>
> Your assessment is correct: an aggregate header like:
>
> header1: val1, val2
>
> should be converted to this for the HttpRequest:
>
> header1: val1
> header1: val2
No, this is not correct.
You are allowed to do that only if the application knows it mak
On Friday 16 August 2002 09:43 pm, Patrick Luby wrote:
> Tomcat 4 used to do this conversion correctly but then it stopped doing
> the conversion a few months ago.
>
I'll bet dollars to donuts that it was exactly when Coyote was brought in as
the connector, replacing the older o.a.c.connector.ht
Are you sure? Well, of course you're sure. What I mean is, is this a
good interpretation of the spec?
The spec is not crystal clear on this point [SRV.4.3], as it discusses
multiple headers with the same name, and multiple values for headers,
but that seems to be within context of multiple hea
- Original Message -
From: "Patrick Luby" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Friday, August 16, 2002 6:43 PM
Subject: Re: Watchdog aggregation of headers may be incorrect
> Steve,
>
> Your assess
Steve,
Your assessment is correct: an aggregate header like:
header1: val1, val2
should be converted to this for the HttpRequest:
header1: val1
header1: val2
Tomcat 4 used to do this conversion correctly but then it stopped doing
the conversion a few months ago.
This should be fixe
Watchdog now merges headers, by design. ie (from the checking message)
Modified logic to send duplicate headers as one aggregated header vs. two
headers:
header1: val1
header1: val2
-will now be-
header1: val1, val2
Due to this, it looks like a couple of tests are failing. GetHeaders
20 matches
Mail list logo
