- From: Alex Rousskov <rousskov@measurement-factory.com>
- Date: Mon, 1 May 2017 11:03:15 -0600
- To: HTTP working group mailing list <ietf-http-wg@w3.org>
On 05/01/2017 10:17 AM, Poul-Henning Kamp wrote: > To be brutally honest, it has never been entirely clear what the goal > of this document is :-) I applaud your honesty, but since this is a WG draft now, the lack of a clear goal is no longer your personal fault :-). I hope we can fix that flaw before it becomes fatal. >> [...] and we should focus on a small set of unambiguous elements [...] > That is simply not possible for existing headers. Can we define all existing headers using a small set of unambiguous elements? Probably not, but that should not be our goal. We only need to cover common usage of common fields plus (nearly) all future ones. > Current header definitions make 3.14159265 a valid "token": Yes, but _we_ do not have to define 3.14159265 as both "number" and "identifier". AFAICT, we can define it as "number" only, excluding tokens that start with [-]DIGIT from our "identifier" definition. Ambiguity problem solved! This works for both parsers and generators. > So there is no way to tell what you have when you encounter that, > unless you know which header you are in and where in that header > you are. There is a way to tell for all the important use cases AFAICT. Yes, if I am building a generic parser that wants to understand senders intent in _all_ legacy cases, then my parse tree cannot use some of the draft elements "as is", but since understanding senders intent in all cases is an unsolvable problem in legacy HTTP, we should not focus on that esoteric use case too much! A generic parser that might confuse a number with identifier is possible to build for legacy HTTP while perfect parsers are possible for new >fields<, and that is good enough. Same for generators. HTH, Alex.
Received on Monday, 1 May 2017 17:03:45 UTC