Re: parsing URI (references) according to RFC 3986

On 2011-06-20 00:18, Chris Weber wrote:
> 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.

Also a good idea.

Unfortunately then we can't simple use test cases verbatim, and need to 
modifiy them before inclusion.

Hmmm.

Received on Monday, 20 June 2011 05:24:23 UTC