Re: Validation error from base 64 encoded data in an object element.

Jukka K. Korpela" <jkorpela@cs.tut.fi>, 2013-11-30 15:40 +0200:

> 2013-11-30 14:45, Michael[tm] Smith wrote:
> 
> >>Maybe I missed something; where does "URL Living Standard" say something
> >>about stripping line breaks?
> >
> >The parts of the algorithms where U+000A and U+000D are handled
> 
> It says in different contexts that U+000A and U+000D cause “parse error”.

It says more than that

> In normal spec parlance, that would mean that the input does not
> constitute a URL;

I guess that depends on what specs you're accustomed to reading.
But anyway it doesn't mean that parsing fails.

> here it is pseudo-defined by saying this: “A parse error indicates a
> non-fatal mismatch between input and requirements. User agents are
> encouraged to expose parse errors somehow.”

Consistent with how the HTML spec defines parse errors.

> If the intent is that the offending character is just ignored, then this
> should be said.

It is said.

If you follow the algorithms, it's clear what happens with U+000A and U+000D
(they don't get appended to the buffer the parsed URL is formed from).

> I think the normal interpretation is that “parse error” terminates
> parsing,

Only if by normal you mean XML

The URL spec calls them "parse errors" not "parse failures". It doesn't say
they're fatal. It doesn't say to fail, abort, stop parsing or otherwise do
some kind of early return due to them.

> or at least means that parsing cannot return a valid item.

Validity isn't relevant to the output that gets returned from URL parsing. The
parsing either succeeds and returns a URL object, or it fails.

-- 
Michael[tm] Smith http://people.w3.org/mike

Received on Saturday, 30 November 2013 17:15:35 UTC