Re: parsing URI (references) according to RFC 3986

On 6/19/2011 10:33 AM, Julian Reschke wrote:
> On 2011-06-18 19:15, Chris Weber wrote:
>> On 6/18/2011 4:56 AM, Julian Reschke wrote:
>
> That looks like a cool approach for testing host name parsing and
> resolution!

I scrapped the GUID idea, which worked well but only gave me the benefit 
of being able to correlate a given test Id with the specific Web browser 
that initiated the DNS request (e.g. there's nothing in a DNS request 
which I could otherwise use to identify the browser).

I expect most browsers are using the platform OS to resolve DNS so I'm 
okay with this for now.  Of course there's always apps like Skype which 
I believe uses it's own DNS libraries...

>> Otherwise, what are your thoughts on including an easily identifiable
>> token that could be placed anywhere in the test string?
>
> Good question.
>
> For generic parsing tests, there really isn't a single component on
> which presence we can rely on. For instance, we may have relative
> references (no authority), empty paths, missing queries, or missing
> fragment identifiers.

I understand and am still wondering if a generic Id format could be used 
in the other parts that are not missing.

> For now my plan is to group the tests into groups (like "RFC3986",
> "RFC2397"...), and build a test id by numbering within the groups; then,
> for the more "interesting" tests we can assign a unique identifier
> within that group.
>
> Best regards, Julian

I like the grouping idea.  Right now I'm pulling as much as I can from 
Adam's Webkit test suite, into the XML format mentioned earlier.  I'm 
still including the test Id as part of the hostname (e.g. 
http://0013.iris.test.ing).  If you wanted to be super generic across 
all groups could you have a test Id format that was unique enough (e.g. 
6 digits) that it could easily be found with a regex, and was usable in 
cases where any given component was missing?  Where 000013 is the test 
id below:

http://000013.iris.test.ing
http:000013
http\\000013
000013:foo/bar
mailto:000013@example.com
mailto:chris@000013.iris.test.ing
urn:ietf:rfc:000013
opaquelocktoken:000013e0-1bb3-11df-9f3e-a5b17f9068f4
data:,A%20000013%20note%25foo#bar

In each of these cases I should be able to identify the test id within 
the string.

thanks,
Chris

Received on Sunday, 19 June 2011 22:18:54 UTC