Re: RFC 7230..7235 Parsing Conformance?
On 05/17/2016 02:53 PM, William A Rowe Jr wrote:
> (Note that HT is a CTL, right, so it appears to be doubly excluded, no?)
> CHAR is US-ASCII 0-127.
I noticed that too... It seems odd, but it's water under the bridge now,
I guess.
> The characters missing above from tchar are '"', '(', ')', ',', '/',
> ':', ';', '<', '=', '>', '?', '@', '[', '\', ']', '{', '}' which
> corresponds to this delimiter list, and to the RFC2616 list. VCHAR is
> clearly US-ASCII 20-7E, possibly includes tab. (Tabs are visible spacing.)
RFC 7230 defers to RFC 5234 [1] for VCHAR:
> VCHAR = %x21-7E
> ; visible (printing) characters
So neither spaces nor tabs by my reading.
> So my concerns may have been unfounded, but reviewing the new spec
> against implementation still seems prudent.
+1 to that.
Getting back to your original question, then: if there are any
differences that do come up, I personally think it would be nice if the
new rules were used by default in the next major release, but
case-by-case consideration would probably be appropriate for now.
--Jacob
[1] https://tools.ietf.org/html/rfc5234#appendix-B.1
Re: RFC 7230..7235 Parsing Conformance?
Based on Jason's question...
On Tue, May 17, 2016 at 1:31 PM, William A Rowe Jr
wrote:
> On Tue, May 17, 2016 at 1:00 PM, Julian Reschke
> wrote:
>
>> On 2016-05-17 19:01, Graham Leggett wrote:
>>
>>> On 17 May 2016, at 6:43 PM, William A Rowe Jr
>>> wrote:
>>>
>>> Wondering what other contributors are thinking on this topic.
We have a number of changes in the ABNF grammar between
RFC2616 and RFC7230..7235. Do we want trunk 2.6/3.0 to be
an entirely RFC723x generation server, and drop all support for
RFC2616?
Do we want to backport these changes to 2.4.x? If so, what
mechanism do we want to toggle the behavior of the server
between 2616 and 7230..7235?
We can presume a small performance hit in any conditional
operation, especially when those decisions apply to tight parsing
loop. Toggling between two different parser implementations would
probably be a bit more efficient than conditionals within a parser
itself.
>>>
>>> Can you give some examples to get a sense of the extent of this?
>>>
>> +1 to the question; I'd like to see examples as well...
>>
>> I believe we only changed the ABNF when we came to the conclusion that
>> the old one was incorrect, or did not reflect what implementations do in
>> practice.
>>
>
> One of the more significant is the change to token,
> https://tools.ietf.org/html/rfc2616#section-2.2
>
> token = 1*
>
>
separators = "(" | ")" | "<" | ">" | "@"
| "," | ";" | ":" | "\" | <">
| "/" | "[" | "]" | "?" | "="
| "{" | "}" | SP | HT
(Note that HT is a CTL, right, so it appears to be doubly excluded, no?)
CHAR is US-ASCII 0-127.
> vs https://tools.ietf.org/html/rfc7230#section-3.2.6
>
> token = 1*tchar
>
> tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*"
> / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~"
> / DIGIT / ALPHA
> ; any VCHAR, except delimiters
>
>
"Delimiters are chosen
from the set of US-ASCII visual characters not allowed in a token
(DQUOTE and "(),/:;<=>?@[\]{}")."
The characters missing above from tchar are '"', '(', ')', ',', '/', ':',
';', '<', '=', '>', '?', '@', '[', '\', ']', '{', '}' which corresponds to
this delimiter list, and to the RFC2616 list. VCHAR is clearly US-ASCII
20-7E, possibly includes tab. (Tabs are visible spacing.)
So my concerns may have been unfounded, but reviewing the new spec against
implementation still seems prudent. As I come across specifics we can
discuss those, sorry for my confusion.
Re: RFC 7230..7235 Parsing Conformance?
On 05/17/2016 11:31 AM, William A Rowe Jr wrote: > One of the more significant is the change to token, > https://tools.ietf.org/html/rfc2616#section-2.2 > > token = 1* > > > vs https://tools.ietf.org/html/rfc7230#section-3.2.6 > > token = 1*tchar > > tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" > / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~" > / DIGIT / ALPHA > ; any VCHAR, except delimiters Is there a difference between these, other than that the first definition is subtractive and the second is additive? I did a quick check through an ASCII table and they seemed to be equivalent to me. --Jacob
Re: RFC 7230..7235 Parsing Conformance?
On Tue, May 17, 2016 at 9:43 AM, William A Rowe Jr wrote: > Do we want to backport these changes to 2.4.x? If so, what > mechanism do we want to toggle the behavior of the server > between 2616 and 7230..7235? I would piggyback it on the "HttpProtocol" strict stuff that also needs backporting.
Re: RFC 7230..7235 Parsing Conformance?
On Tue, May 17, 2016 at 1:00 PM, Julian Reschke wrote: > On 2016-05-17 19:01, Graham Leggett wrote: > >> On 17 May 2016, at 6:43 PM, William A Rowe Jr >> wrote: >> >> Wondering what other contributors are thinking on this topic. >>> >>> We have a number of changes in the ABNF grammar between >>> RFC2616 and RFC7230..7235. Do we want trunk 2.6/3.0 to be >>> an entirely RFC723x generation server, and drop all support for >>> RFC2616? >>> >>> Do we want to backport these changes to 2.4.x? If so, what >>> mechanism do we want to toggle the behavior of the server >>> between 2616 and 7230..7235? >>> >>> We can presume a small performance hit in any conditional >>> operation, especially when those decisions apply to tight parsing >>> loop. Toggling between two different parser implementations would >>> probably be a bit more efficient than conditionals within a parser >>> itself. >>> >> >> Can you give some examples to get a sense of the extent of this? >> > +1 to the question; I'd like to see examples as well... > > I believe we only changed the ABNF when we came to the conclusion that the > old one was incorrect, or did not reflect what implementations do in > practice. > One of the more significant is the change to token, https://tools.ietf.org/html/rfc2616#section-2.2 token = 1* vs https://tools.ietf.org/html/rfc7230#section-3.2.6 token = 1*tchar tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA ; any VCHAR, except delimiters This has a lot of tangential effects. My plan was to begin auditing the code against spec and begin assembling patches. My question in the note above is how we will generally handle the shift from one spec to the next, and what we will promise our users (use 2.next/3.0 for conformance? Use 2.4 to retain 2616 behavior?)
Re: RFC 7230..7235 Parsing Conformance?
On 2016-05-17 19:01, Graham Leggett wrote: On 17 May 2016, at 6:43 PM, William A Rowe Jr wrote: Wondering what other contributors are thinking on this topic. We have a number of changes in the ABNF grammar between RFC2616 and RFC7230..7235. Do we want trunk 2.6/3.0 to be an entirely RFC723x generation server, and drop all support for RFC2616? Do we want to backport these changes to 2.4.x? If so, what mechanism do we want to toggle the behavior of the server between 2616 and 7230..7235? We can presume a small performance hit in any conditional operation, especially when those decisions apply to tight parsing loop. Toggling between two different parser implementations would probably be a bit more efficient than conditionals within a parser itself. Can you give some examples to get a sense of the extent of this? Regards, Graham +1 to the question; I'd like to see examples as well... I believe we only changed the ABNF when we came to the conclusion that the old one was incorrect, or did not reflect what implementations do in practice. Best regards, Julian
Re: RFC 7230..7235 Parsing Conformance?
On 17 May 2016, at 6:43 PM, William A Rowe Jr wrote: > Wondering what other contributors are thinking on this topic. > > We have a number of changes in the ABNF grammar between > RFC2616 and RFC7230..7235. Do we want trunk 2.6/3.0 to be > an entirely RFC723x generation server, and drop all support for > RFC2616? > > Do we want to backport these changes to 2.4.x? If so, what > mechanism do we want to toggle the behavior of the server > between 2616 and 7230..7235? > > We can presume a small performance hit in any conditional > operation, especially when those decisions apply to tight parsing > loop. Toggling between two different parser implementations would > probably be a bit more efficient than conditionals within a parser > itself. Can you give some examples to get a sense of the extent of this? Regards, Graham —
RFC 7230..7235 Parsing Conformance?
Wondering what other contributors are thinking on this topic. We have a number of changes in the ABNF grammar between RFC2616 and RFC7230..7235. Do we want trunk 2.6/3.0 to be an entirely RFC723x generation server, and drop all support for RFC2616? Do we want to backport these changes to 2.4.x? If so, what mechanism do we want to toggle the behavior of the server between 2616 and 7230..7235? We can presume a small performance hit in any conditional operation, especially when those decisions apply to tight parsing loop. Toggling between two different parser implementations would probably be a bit more efficient than conditionals within a parser itself.
