Re: [apps-discuss] character repertoire for fragment identifiers

[Sam Ruby <[e-mail]>]

On 01/12/2015 11:03 AM, [e-mail] wrote:
> *> From:* Sam Ruby <mailto:[e-mail]>
> *> *
> *> *Again, it is my hope/expectation that by year end every single one of
> *> *the parsers that I have looked out (with the possible/probable
> exception
> *> *of Perl) will NOT percent encode fragments.
> *> *…
> *> *
> *> *I have published a lot of test values that I am looking for people to
> *> *work through with me.  Cooperation amongst browser vendors in this
> *> *effort is increasing.  I have yet to find anybody on this list willing
> *> *to look at this data.
>
> I have looked at the test data.  Specifically I have looked at the
> comparisons between the .NET framework (csharp) URI parser and the
> reference implementation.

Thanks for doing this!

> I’m not sure how you ever expect to obtain a consistent result between a
> library that returns errors along with a parsed result and one that
> throws an exception and aborts parsing upon encountering an error.  Is
> it your expectation that the .Net framework stops throwing exceptions
> when URI parsing?

At the moment, I'm gathering data and sharing results.

> Also, regarding escaping of fragment identifiers, in your csharp test
> program you use Uri.Fragment, which is explicitly documented to return
> an escaped fragment.  If the developer does not wish the fragment to be
> escaped then they are free to use,
>
> Uri.GetComponents(UriComponents.Fragment, UriFormat.Unescaped)

Fixed.  Thanks!

https://github.com/webspecs/url/commit/1ac9fb4279f90f6c349ee8954159ea48e99cbdef

https://url.spec.whatwg.org/interop/test-results/730127041a

> Different languages do things in different ways.  Trying get every URL
> parsing library to behave identically just feels like an ocean boiling
> exercise.

In the case of browsers and HTML, different browsers doing different 
things was a major pain point, and large strides have been made over the 
past several years on addressing this.

I hope to make things better (more compatible, more interoperable) for 
developers.  If the best I can do is document what options need to be 
used to get compatible results, then that's what I will do.

> Darrel

- Sam Ruby