- From: David W. Morris <dwm@xpasc.com>
- Date: Wed, 4 Jun 1997 14:55:54 -0700 (PDT)
- To: Ross Patterson <Ross_Patterson@ns.reston.vmd.sterling.com>
- Cc: http-wg@cuckoo.hpl.hp.com
On Wed, 4 Jun 1997, Ross Patterson wrote: > David W. Morris" <dwm@xpasc.com> writes: > That's an interesting definition of "no surprises", unless you mean that > a quoted-string is always treated identically, regardless of context. Yup, for something as fundamental to modern programming languages as quoted strings, there ought to be a real good reason for changing the behavior. > I'd count processing of characters within a supposedly opaque value as > quite surprising. But my point is that the quoted string IS NOT the value which is opaque, it becomes the opaque value after resolving quoted pairs. > Much of the world is neither C nor Unix, and it certainly is arguable > whether many HTTP implementers had existing RFC822-compliant lexical > analyzers to steal the quoted-string support from. Given that HTTP 1.0 > had an extremely simple quoted-string, I'll bet that any HTTP > implementations that incorrectly accept quoted-pairs can be traced to > a single code source. Not me, I crib no code, and I can almost guarantee I've written parsers which handle quoted pairs in the very generic C sense. Sloppy perhaps, but no more so than defining a quoted string which does't at least allow for escaping " and \ characters. A parser which simply treats the single character following \ as a simple character is much easier to code than a bunch of special cases. Adding to that translation for a few cases is still easy. The parser eats two characters and outputs one. But at this point I'm not arguing for or against anything except the quoted pair concept. Not \n and not 0xa parsing. David Morris
Received on Wednesday, 4 June 1997 15:01:18 UTC