subject:"\[jetty\-users\] org.eclipse.jetty.http.HttpField"

Re: [jetty-users] org.eclipse.jetty.http.HttpField

2020-10-30 Thread Nils Kilden-Pedersen



On Fri, Oct 30, 2020 at 3:45 AM Greg Wilkins  wrote:

>
> So wrote this test code:
>
> public void testEtag()
> {
> HttpFields fields = new HttpFields();
> fields.add("ETag", "W/\"1\",W/2");
> fields.add("ETag", "W/\"3\"");
>
> System.err.println("Collections.list(fields.getValues(\"Etag\"))");
> Collections.list(fields.getValues("Etag")).forEach(System.err::println);
> System.err.println("Collections.list(fields.getValues(\"Etag\", \",\"))");
> Collections.list(fields.getValues("Etag", 
> ",")).forEach(System.err::println);
> System.err.println("fields.getCSV(\"Etag\", false)");
> fields.getCSV("Etag", false).forEach(System.err::println);
> System.err.println("fields.getCSV(\"Etag\", true)");
> fields.getCSV("Etag", true).forEach(System.err::println);
> }
>
> which cage the output:
>
> Collections.list(fields.getValues("Etag"))
> W/"1",W/2
> W/"3"
> Collections.list(fields.getValues("Etag", ","))
> W/1
> W/2
> W/3
> fields.getCSV("Etag", false)
> W/1
> W/2
> W/3
> fields.getCSV("Etag", true)
> W/"1"
> W/2
> W/"3"
>
>
> So fields.getCSV("Etag", true) is the method you want.
> Note also that fields.getValues("Etag", ",") is deprecated!
>
> --
> Greg Wilkins  CTO http://webtide.com
> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jetty-users
>
___
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/jetty-users

Re: [jetty-users] org.eclipse.jetty.http.HttpField

2020-10-30 Thread Greg Wilkins

So wrote this test code:

public void testEtag()
{
HttpFields fields = new HttpFields();
fields.add("ETag", "W/\"1\",W/2");
fields.add("ETag", "W/\"3\"");

System.err.println("Collections.list(fields.getValues(\"Etag\"))");
Collections.list(fields.getValues("Etag")).forEach(System.err::println);
System.err.println("Collections.list(fields.getValues(\"Etag\", \",\"))");
Collections.list(fields.getValues("Etag",
",")).forEach(System.err::println);
System.err.println("fields.getCSV(\"Etag\", false)");
fields.getCSV("Etag", false).forEach(System.err::println);
System.err.println("fields.getCSV(\"Etag\", true)");
fields.getCSV("Etag", true).forEach(System.err::println);
}

which cage the output:

Collections.list(fields.getValues("Etag"))
W/"1",W/2
W/"3"
Collections.list(fields.getValues("Etag", ","))
W/1
W/2
W/3
fields.getCSV("Etag", false)
W/1
W/2
W/3
fields.getCSV("Etag", true)
W/"1"
W/2
W/"3"


So fields.getCSV("Etag", true) is the method you want.
Note also that fields.getValues("Etag", ",") is deprecated!

-- 
Greg Wilkins  CTO http://webtide.com
___
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/jetty-users

Re: [jetty-users] org.eclipse.jetty.http.HttpField

2020-10-29 Thread Greg Wilkins

Ohhh and yes section 2.3 doesn't comply with 2.6 but 2.6 does only
apply to "most" values.

... and you wonder why implementations of these specs sometimes get it
wrong:)

On Fri, 30 Oct 2020, 00:32 Greg Wilkins,  wrote:

> My first thought is that Nils could be right when he says that getValues
> is needlessly removing quotes.
>
> That method was never really well specified as it's based in neither the
> http nor servlets specification. It was originally a jack of all trades
> method that worked for most cases.
>
> We've not moved much of our previous handling to other methods like getCSV
> and getQualityCSV, with more precise behaviour.
>
> In this case, getCSV passed a boolean to keep quotes will probably do the
> job you need.
>
> I'll do a bit more of a review and comment more tomorrow if I get a
> chance,... But maybe Monday.
>
> Cheers
>
> On Thu, 29 Oct 2020, 22:28 Joakim Erdfelt,  wrote:
>
>> Per the spec you linked ...
>>
>>  ETag   = entity-tag
>>
>>  entity-tag = [ weak ] opaque-tag
>>  weak   = %x57.2F ; "W/", case-sensitive
>>  opaque-tag = DQUOTE *etagc DQUOTE
>>  etagc  = %x21 / %x23-7E / obs-text
>> ; VCHAR except double quotes, plus obs-text
>>
>>
>> That means the "ETag" field is an "entity-tag"
>> Which can start with an optional "weak", and must have an "opaque-tag"
>>
>> The definition fo "weak" is that it is always the 2 characters "W/" and
>> the case must be preserved.
>>
>> The "opaque-tag" is almost the same as what the http/1.1 spec level
>> "quoted-string" definition is.
>> Except that it doesn't allow space character.
>>
>> Greg, what's you take on this?
>> This would mean a new Special Case handling for a field value that isn't
>> "Set-Cookie".
>> There's some accepted errata published after RFC7232 about ETag, but only
>> related to space in etagc.
>> No errata on RFC7230 about other special case handling of field-values.
>>
>> Joakim Erdfelt / joa...@webtide.com
>>
>>
>> On Thu, Oct 29, 2020 at 4:07 PM Cantor, Scott  wrote:
>>
>>> On 10/29/20, 4:54 PM, "jetty-users-boun...@eclipse.org on behalf of
>>> Joakim Erdfelt" >> joa...@webtide.com> wrote:
>>>
>>> >Your Example 2:
>>> >If-Match: W/"ab3>5ef1bc78", W/"5be73a9c523"
>>> >
>>>  >   This is a field of name "If-Match".
>>>  >   It has 2 values, both of which are in violation of the spec.
>>>
>>> https://tools.ietf.org/html/rfc7232#section-2.3
>>>
>>> Am I missing something? That middle one seems to explicitly match your
>>> examples that you think are in violation...
>>>
>>> (I don't mean to barge into the thread, but I have some uses of ETag in
>>> our code stack and I want to be able to accurately assess how we're using
>>> it.)
>>>
>>> -- Scott
>>>
>>>
>>> ___
>>> jetty-users mailing list
>>> jetty-users@eclipse.org
>>> To unsubscribe from this list, visit
>>> https://www.eclipse.org/mailman/listinfo/jetty-users
>>>
>> ___
>> jetty-users mailing list
>> jetty-users@eclipse.org
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/jetty-users
>>
>
___
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/jetty-users

Re: [jetty-users] org.eclipse.jetty.http.HttpField

2020-10-29 Thread Greg Wilkins

My first thought is that Nils could be right when he says that getValues is
needlessly removing quotes.

That method was never really well specified as it's based in neither the
http nor servlets specification. It was originally a jack of all trades
method that worked for most cases.

We've not moved much of our previous handling to other methods like getCSV
and getQualityCSV, with more precise behaviour.

In this case, getCSV passed a boolean to keep quotes will probably do the
job you need.

I'll do a bit more of a review and comment more tomorrow if I get a
chance,... But maybe Monday.

Cheers

On Thu, 29 Oct 2020, 22:28 Joakim Erdfelt,  wrote:

> Per the spec you linked ...
>
>  ETag   = entity-tag
>
>  entity-tag = [ weak ] opaque-tag
>  weak   = %x57.2F ; "W/", case-sensitive
>  opaque-tag = DQUOTE *etagc DQUOTE
>  etagc  = %x21 / %x23-7E / obs-text
> ; VCHAR except double quotes, plus obs-text
>
>
> That means the "ETag" field is an "entity-tag"
> Which can start with an optional "weak", and must have an "opaque-tag"
>
> The definition fo "weak" is that it is always the 2 characters "W/" and
> the case must be preserved.
>
> The "opaque-tag" is almost the same as what the http/1.1 spec level
> "quoted-string" definition is.
> Except that it doesn't allow space character.
>
> Greg, what's you take on this?
> This would mean a new Special Case handling for a field value that isn't
> "Set-Cookie".
> There's some accepted errata published after RFC7232 about ETag, but only
> related to space in etagc.
> No errata on RFC7230 about other special case handling of field-values.
>
> Joakim Erdfelt / joa...@webtide.com
>
>
> On Thu, Oct 29, 2020 at 4:07 PM Cantor, Scott  wrote:
>
>> On 10/29/20, 4:54 PM, "jetty-users-boun...@eclipse.org on behalf of
>> Joakim Erdfelt" > joa...@webtide.com> wrote:
>>
>> >Your Example 2:
>> >If-Match: W/"ab3>5ef1bc78", W/"5be73a9c523"
>> >
>>  >   This is a field of name "If-Match".
>>  >   It has 2 values, both of which are in violation of the spec.
>>
>> https://tools.ietf.org/html/rfc7232#section-2.3
>>
>> Am I missing something? That middle one seems to explicitly match your
>> examples that you think are in violation...
>>
>> (I don't mean to barge into the thread, but I have some uses of ETag in
>> our code stack and I want to be able to accurately assess how we're using
>> it.)
>>
>> -- Scott
>>
>>
>> ___
>> jetty-users mailing list
>> jetty-users@eclipse.org
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/jetty-users
>>
> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jetty-users
>
___
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/jetty-users

Re: [jetty-users] org.eclipse.jetty.http.HttpField

2020-10-29 Thread Joakim Erdfelt

Per the spec you linked ...

 ETag   = entity-tag

 entity-tag = [ weak ] opaque-tag
 weak   = %x57.2F ; "W/", case-sensitive
 opaque-tag = DQUOTE *etagc DQUOTE
 etagc  = %x21 / %x23-7E / obs-text
; VCHAR except double quotes, plus obs-text

That means the "ETag" field is an "entity-tag"
Which can start with an optional "weak", and must have an "opaque-tag"

The definition fo "weak" is that it is always the 2 characters "W/" and the
case must be preserved.

The "opaque-tag" is almost the same as what the http/1.1 spec level
"quoted-string" definition is.
Except that it doesn't allow space character.

Greg, what's you take on this?
This would mean a new Special Case handling for a field value that isn't
"Set-Cookie".
There's some accepted errata published after RFC7232 about ETag, but only
related to space in etagc.
No errata on RFC7230 about other special case handling of field-values.

Joakim Erdfelt / joa...@webtide.com

On Thu, Oct 29, 2020 at 4:07 PM Cantor, Scott  wrote:

> On 10/29/20, 4:54 PM, "jetty-users-boun...@eclipse.org on behalf of
> Joakim Erdfelt"  joa...@webtide.com> wrote:
>
> >Your Example 2:
> >If-Match: W/"ab3>5ef1bc78", W/"5be73a9c523"
> >
>  >   This is a field of name "If-Match".
>  >   It has 2 values, both of which are in violation of the spec.
>
> https://tools.ietf.org/html/rfc7232#section-2.3
>
> Am I missing something? That middle one seems to explicitly match your
> examples that you think are in violation...
>
> (I don't mean to barge into the thread, but I have some uses of ETag in
> our code stack and I want to be able to accurately assess how we're using
> it.)
>
> -- Scott
>
>
> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jetty-users
>
___
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/jetty-users

Re: [jetty-users] org.eclipse.jetty.http.HttpField

2020-10-29 Thread Nils Kilden-Pedersen

Bad example perhaps with If-Match, but substitute for If-None-Match and
it’s not a violation.

However, ETags are opaque, so it’s not clear to me how I would distinguish
the following:

If-None-Match: W/"RYNBLKMNQ/LK"
If-None-Match: "W/RYNBLKMNQ/LK"

Which one is weak and which one isn’t?

On Thu, Oct 29, 2020 at 3:54 PM Joakim Erdfelt joa...@webtide.com
 wrote:

So there's 2 topics here, both about field values.
>
> 1. What does comma mean?
> 2. What does dquote mean?
>
> If there is a comma present, and it's not within a DQUOTE pair, then
> that's the delimiter between field-values.
>
> So that means ...
>
> *Example 1:*
>
> X-Foo: apple, banana, pear
>
> Is a field of name "X-Foo", with 3 values:
> 1. apple
> 2. banana
> 3. pear
>
> This can also be represented across multiple headers of the same name.
>
> *Example 2:*
>
> X-Foo: apple
> X-Foo: banana
> X-Foo: pear
>
> Those 2 examples are equivalent field definitions.
>
> Those 3 values, as they are written, are considered "token" field values
> per spec.
>
> See https://tools.ietf.org/html/rfc7230#section-3.2.6
>
> You can have a field value of either:
> 1. a token
> 2. quoted-string
> 3. comment
>
> The rules for "token" are ...
>
>  token  = 1*tchar
>
>  tchar  = "!" / "#" / "$" / "%" / "&" / "'" / "*"
> / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~"
> / DIGIT / ALPHA
> ; any VCHAR, except delimiters
>
>
> Also, it notes that delimiters are (DQUOTE and "(),/:;<=>?@[\]{}")
>
>
> The rules for "quoted-string" are ...
>
>  quoted-string  = DQUOTE *( qdtext / quoted-pair ) DQUOTE
>  qdtext = HTAB / SP /%x21 / %x23-5B / %x5D-7E / obs-text
>  obs-text   = %x80-FF
>
>
> If we take these rules and apply it to your stated example strings ...
>
> *Your Example 1:*
>
> If-Match: "ab35ef1bc78", "5be73a9c523"
>
> This is a field of name "If-Match", with 2 quoted-string values.
>
> 1. ab35ef1bc78
> 2. 5be73a9c523
>
> *Your Example 2:*
>
> If-Match: W/"ab35ef1bc78", W/"5be73a9c523"
>
> This is a field of name "If-Match".
> It has 2 values, both of which are in violation of the spec.
> Why?
> This is started to be parsed as a token, as it doesn't start with DQUOTE.
> This field-value has 3 forbidden delimiter characters, the "/" is invalid,
> and so are the DQUOTE characters.
> This example doesn't fit the definition for quoted-string either, as it
> doesn't start with DQUOTE.
>
> If your example was ...
>
> If-Match: "W/ab35ef1bc78", "W/5be73a9c523"
>
> Then you would satisfy the quoted-string rules. (as the "/" is %x2F and
> within the allowed qdtext definition).
> And the parsed definition would be ..
>
> Field with name "If-Match", with a value list
>
> 1. W/ab35ef1bc78
> 2. W/5be73a9c523
>
> Joakim Erdfelt / joa...@webtide.com
>
>
> On Thu, Oct 29, 2020 at 2:21 PM Cantor, Scott  wrote:
>
>> On 10/29/20, 3:14 PM, "jetty-users-boun...@eclipse.org on behalf of Nils
>> Kilden-Pedersen" > nil...@gmail.com> wrote:
>>
>> >I disagree. The quotes are part of the value and are significant.
>>
>> I agree.
>>
>> I was curious about this and followed the thread because I make use of
>> the etags feature in the DefaultServlet. It seems to operate properly so
>> far as it goes, but that may be due to simply expecting and handling the
>> fact that the quotes are gone, or by not properly handling weak vs.strong
>> comparison.
>>
>> But if something behind the server were looking at the header value, it
>> would be getting a corrupted value out to compare with its own copy of the
>> tag if it had produced it.
>>
>> -- Scott
>>
>>
>> ___
>> jetty-users mailing list
>> jetty-users@eclipse.org
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/jetty-users
>>
> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jetty-users
>
___
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/jetty-users

Re: [jetty-users] org.eclipse.jetty.http.HttpField

2020-10-29 Thread Cantor, Scott

On 10/29/20, 4:54 PM, "jetty-users-boun...@eclipse.org on behalf of Joakim 
Erdfelt"  
wrote:

>Your Example 2:
>If-Match: W/"ab3>5ef1bc78", W/"5be73a9c523"
>
 >   This is a field of name "If-Match".
 >   It has 2 values, both of which are in violation of the spec.

https://tools.ietf.org/html/rfc7232#section-2.3

Am I missing something? That middle one seems to explicitly match your examples 
that you think are in violation...

(I don't mean to barge into the thread, but I have some uses of ETag in our 
code stack and I want to be able to accurately assess how we're using it.)

-- Scott


___
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/jetty-users

Re: [jetty-users] org.eclipse.jetty.http.HttpField

2020-10-29 Thread Joakim Erdfelt

So there's 2 topics here, both about field values.

1. What does comma mean?
2. What does dquote mean?

If there is a comma present, and it's not within a DQUOTE pair, then that's
the delimiter between field-values.

So that means ...

*Example 1:*

X-Foo: apple, banana, pear

Is a field of name "X-Foo", with 3 values:
1. apple
2. banana
3. pear

This can also be represented across multiple headers of the same name.

*Example 2:*

X-Foo: apple
X-Foo: banana
X-Foo: pear

Those 2 examples are equivalent field definitions.

Those 3 values, as they are written, are considered "token" field values
per spec.

See https://tools.ietf.org/html/rfc7230#section-3.2.6

You can have a field value of either:
1. a token
2. quoted-string
3. comment

The rules for "token" are ...

 token  = 1*tchar

 tchar  = "!" / "#" / "$" / "%" / "&" / "'" / "*"
/ "+" / "-" / "." / "^" / "_" / "`" / "|" / "~"
/ DIGIT / ALPHA
; any VCHAR, except delimiters

Also, it notes that delimiters are (DQUOTE and "(),/:;<=>?@[\]{}")

The rules for "quoted-string" are ...

 quoted-string  = DQUOTE *( qdtext / quoted-pair ) DQUOTE
 qdtext = HTAB / SP /%x21 / %x23-5B / %x5D-7E / obs-text
 obs-text   = %x80-FF

If we take these rules and apply it to your stated example strings ...

*Your Example 1:*

If-Match: "ab35ef1bc78", "5be73a9c523"

This is a field of name "If-Match", with 2 quoted-string values.

1. ab35ef1bc78
2. 5be73a9c523

*Your Example 2:*

If-Match: W/"ab35ef1bc78", W/"5be73a9c523"

This is a field of name "If-Match".
It has 2 values, both of which are in violation of the spec.
Why?
This is started to be parsed as a token, as it doesn't start with DQUOTE.
This field-value has 3 forbidden delimiter characters, the "/" is invalid,
and so are the DQUOTE characters.
This example doesn't fit the definition for quoted-string either, as it
doesn't start with DQUOTE.

If your example was ...

If-Match: "W/ab35ef1bc78", "W/5be73a9c523"

Then you would satisfy the quoted-string rules. (as the "/" is %x2F and
within the allowed qdtext definition).
And the parsed definition would be ..

Field with name "If-Match", with a value list

1. W/ab35ef1bc78
2. W/5be73a9c523

Joakim Erdfelt / joa...@webtide.com

On Thu, Oct 29, 2020 at 2:21 PM Cantor, Scott  wrote:

> On 10/29/20, 3:14 PM, "jetty-users-boun...@eclipse.org on behalf of Nils
> Kilden-Pedersen"  nil...@gmail.com> wrote:
>
> >I disagree. The quotes are part of the value and are significant.
>
> I agree.
>
> I was curious about this and followed the thread because I make use of the
> etags feature in the DefaultServlet. It seems to operate properly so far as
> it goes, but that may be due to simply expecting and handling the fact that
> the quotes are gone, or by not properly handling weak vs.strong comparison.
>
> But if something behind the server were looking at the header value, it
> would be getting a corrupted value out to compare with its own copy of the
> tag if it had produced it.
>
> -- Scott
>
>
> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jetty-users
>
___
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/jetty-users

Re: [jetty-users] org.eclipse.jetty.http.HttpField

2020-10-29 Thread Cantor, Scott

On 10/29/20, 3:14 PM, "jetty-users-boun...@eclipse.org on behalf of Nils 
Kilden-Pedersen"  wrote:

>I disagree. The quotes are part of the value and are significant. 

I agree.

I was curious about this and followed the thread because I make use of the 
etags feature in the DefaultServlet. It seems to operate properly so far as it 
goes, but that may be due to simply expecting and handling the fact that the 
quotes are gone, or by not properly handling weak vs.strong comparison.

But if something behind the server were looking at the header value, it would 
be getting a corrupted value out to compare with its own copy of the tag if it 
had produced it.

-- Scott


___
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/jetty-users

Re: [jetty-users] org.eclipse.jetty.http.HttpField

2020-10-29 Thread Nils Kilden-Pedersen

I disagree. The quotes are part of the value and are significant.

What about this:

If-Match: W/"ab35ef1bc78", W/"5be73a9c523"`


On Thu, Oct 29, 2020 at 10:04 AM Joakim Erdfelt  wrote:

> That header ...
>
> `If-Match: "ab35ef1bc78", "5be73a9c523"`
>
> Would be interpreted by https://tools.ietf.org/html/rfc7230#section-3.2
> and https://tools.ietf.org/html/rfc7230#section-3.2.2
>
> as a Field with a List of 2 values.
> Value 1: ab35ef1bc78
> Value 2: 5be73a9c523
>
> ETag is not special here, the only listed special case handling for
> field-value in the spec is `Set-Cookie`.
> See: https://tools.ietf.org/html/rfc7230#section-3.2.2
>
> - Joakim
> Joakim Erdfelt / joa...@webtide.com
>
>
> On Thu, Oct 29, 2020 at 9:47 AM Nils Kilden-Pedersen 
> wrote:
>
>> Yes, that's my point. ETags *require* quotes, but they're being removed.
>>
>> On Thu, Oct 29, 2020 at 9:25 AM Tamás Cservenák 
>> wrote:
>>
>>> To me it seems does requite DQUOTE around it...
>>> https://tools.ietf.org/html/rfc7232#section-2.3
>>>
>>> Thanks
>>> T
>>>
>>> On Thu, Oct 29, 2020 at 3:07 PM Nils Kilden-Pedersen 
>>> wrote:
>>>
 After debugging for a weird problem the entire day yesterday, I finally
 figured out why my ETag value was losing its quotes. For some reason,
 the innocently sounding HttpField.getValues apparently (needlessly?)
 appears to assume that comma separated header values might be quoted (not
 sure why, I don’t think it’s spec), and thus removes *required* quotes
 from etags, causing parsing failure later.

 So, e.g. this header:

 If-Match: "ab35ef1bc78", "5be73a9c523"

 will return invalid ETag values (unquoted).

 I would consider this a bug, but not sure why quote removal is even
 there, as I don’t see the HTTP spec requiring quotes around comma separated
 values.
 ___
 jetty-users mailing list
 jetty-users@eclipse.org
 To unsubscribe from this list, visit
 https://www.eclipse.org/mailman/listinfo/jetty-users

>>> ___
>>> jetty-users mailing list
>>> jetty-users@eclipse.org
>>> To unsubscribe from this list, visit
>>> https://www.eclipse.org/mailman/listinfo/jetty-users
>>>
>> ___
>> jetty-users mailing list
>> jetty-users@eclipse.org
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/jetty-users
>>
> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jetty-users
>
___
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/jetty-users

Re: [jetty-users] org.eclipse.jetty.http.HttpField

2020-10-29 Thread Joakim Erdfelt

That header ...

`If-Match: "ab35ef1bc78", "5be73a9c523"`

Would be interpreted by https://tools.ietf.org/html/rfc7230#section-3.2
and https://tools.ietf.org/html/rfc7230#section-3.2.2

as a Field with a List of 2 values.
Value 1: ab35ef1bc78
Value 2: 5be73a9c523

ETag is not special here, the only listed special case handling for
field-value in the spec is `Set-Cookie`.
See: https://tools.ietf.org/html/rfc7230#section-3.2.2

- Joakim
Joakim Erdfelt / joa...@webtide.com


On Thu, Oct 29, 2020 at 9:47 AM Nils Kilden-Pedersen 
wrote:

> Yes, that's my point. ETags *require* quotes, but they're being removed.
>
> On Thu, Oct 29, 2020 at 9:25 AM Tamás Cservenák 
> wrote:
>
>> To me it seems does requite DQUOTE around it...
>> https://tools.ietf.org/html/rfc7232#section-2.3
>>
>> Thanks
>> T
>>
>> On Thu, Oct 29, 2020 at 3:07 PM Nils Kilden-Pedersen 
>> wrote:
>>
>>> After debugging for a weird problem the entire day yesterday, I finally
>>> figured out why my ETag value was losing its quotes. For some reason,
>>> the innocently sounding HttpField.getValues apparently (needlessly?)
>>> appears to assume that comma separated header values might be quoted (not
>>> sure why, I don’t think it’s spec), and thus removes *required* quotes
>>> from etags, causing parsing failure later.
>>>
>>> So, e.g. this header:
>>>
>>> If-Match: "ab35ef1bc78", "5be73a9c523"
>>>
>>> will return invalid ETag values (unquoted).
>>>
>>> I would consider this a bug, but not sure why quote removal is even
>>> there, as I don’t see the HTTP spec requiring quotes around comma separated
>>> values.
>>> ___
>>> jetty-users mailing list
>>> jetty-users@eclipse.org
>>> To unsubscribe from this list, visit
>>> https://www.eclipse.org/mailman/listinfo/jetty-users
>>>
>> ___
>> jetty-users mailing list
>> jetty-users@eclipse.org
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/jetty-users
>>
> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jetty-users
>
___
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/jetty-users

Re: [jetty-users] org.eclipse.jetty.http.HttpField

2020-10-29 Thread Nils Kilden-Pedersen

Yes, that's my point. ETags *require* quotes, but they're being removed.

On Thu, Oct 29, 2020 at 9:25 AM Tamás Cservenák  wrote:

> To me it seems does requite DQUOTE around it...
> https://tools.ietf.org/html/rfc7232#section-2.3
>
> Thanks
> T
>
> On Thu, Oct 29, 2020 at 3:07 PM Nils Kilden-Pedersen 
> wrote:
>
>> After debugging for a weird problem the entire day yesterday, I finally
>> figured out why my ETag value was losing its quotes. For some reason,
>> the innocently sounding HttpField.getValues apparently (needlessly?)
>> appears to assume that comma separated header values might be quoted (not
>> sure why, I don’t think it’s spec), and thus removes *required* quotes
>> from etags, causing parsing failure later.
>>
>> So, e.g. this header:
>>
>> If-Match: "ab35ef1bc78", "5be73a9c523"
>>
>> will return invalid ETag values (unquoted).
>>
>> I would consider this a bug, but not sure why quote removal is even
>> there, as I don’t see the HTTP spec requiring quotes around comma separated
>> values.
>> ___
>> jetty-users mailing list
>> jetty-users@eclipse.org
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/jetty-users
>>
> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jetty-users
>
___
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/jetty-users

Re: [jetty-users] org.eclipse.jetty.http.HttpField

2020-10-29 Thread Tamás Cservenák

To me it seems does requite DQUOTE around it...
https://tools.ietf.org/html/rfc7232#section-2.3

Thanks
T

On Thu, Oct 29, 2020 at 3:07 PM Nils Kilden-Pedersen 
wrote:

> After debugging for a weird problem the entire day yesterday, I finally
> figured out why my ETag value was losing its quotes. For some reason, the
> innocently sounding HttpField.getValues apparently (needlessly?) appears
> to assume that comma separated header values might be quoted (not sure why,
> I don’t think it’s spec), and thus removes *required* quotes from etags,
> causing parsing failure later.
>
> So, e.g. this header:
>
> If-Match: "ab35ef1bc78", "5be73a9c523"
>
> will return invalid ETag values (unquoted).
>
> I would consider this a bug, but not sure why quote removal is even there,
> as I don’t see the HTTP spec requiring quotes around comma separated values.
> ___
> jetty-users mailing list
> jetty-users@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jetty-users
>
___
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/jetty-users

[jetty-users] org.eclipse.jetty.http.HttpField

2020-10-29 Thread Nils Kilden-Pedersen

After debugging for a weird problem the entire day yesterday, I finally
figured out why my ETag value was losing its quotes. For some reason, the
innocently sounding HttpField.getValues apparently (needlessly?) appears to
assume that comma separated header values might be quoted (not sure why, I
don’t think it’s spec), and thus removes *required* quotes from etags,
causing parsing failure later.

So, e.g. this header:

If-Match: "ab35ef1bc78", "5be73a9c523"

will return invalid ETag values (unquoted).

I would consider this a bug, but not sure why quote removal is even there,
as I don’t see the HTTP spec requiring quotes around comma separated values.
___
jetty-users mailing list
jetty-users@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/jetty-users

Re: [jetty-users] org.eclipse.jetty.http.HttpField

Re: [jetty-users] org.eclipse.jetty.http.HttpField

Re: [jetty-users] org.eclipse.jetty.http.HttpField

Re: [jetty-users] org.eclipse.jetty.http.HttpField

Re: [jetty-users] org.eclipse.jetty.http.HttpField

Re: [jetty-users] org.eclipse.jetty.http.HttpField

Re: [jetty-users] org.eclipse.jetty.http.HttpField

Re: [jetty-users] org.eclipse.jetty.http.HttpField

Re: [jetty-users] org.eclipse.jetty.http.HttpField

Re: [jetty-users] org.eclipse.jetty.http.HttpField

Re: [jetty-users] org.eclipse.jetty.http.HttpField

Re: [jetty-users] org.eclipse.jetty.http.HttpField

Re: [jetty-users] org.eclipse.jetty.http.HttpField

[jetty-users] org.eclipse.jetty.http.HttpField

14 matches

Site Navigation

Mail list logo

Footer information