This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 8953 - URL decomp. IDL attributes when parsing fails
Summary: URL decomp. IDL attributes when parsing fails
Status: RESOLVED WORKSFORME
Alias: None
Product: HTML WG
Classification: Unclassified
Component: pre-LC1 HTML5 spec (editor: Ian Hickson) (show other bugs)
Version: unspecified
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-02-11 14:09 UTC by Julian Reschke
Modified: 2010-10-04 13:58 UTC (History)
6 users (show)

See Also:


Attachments

Description Julian Reschke 2010-02-11 14:09:10 UTC
Please clarify the expected behavior for the case when WEBADDRESSES parsing into components fails, such as for

  http://a[b].example.org/
Comment 1 Ian 'Hixie' Hickson 2010-02-17 21:57:10 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Did Not Understand Request
Change Description: no spec change
Rationale: Could you clarify which concrete case you're talking about? As far as I can tell, all the places that refer to parsing URLs or refer to components of URLs are well-defined in the case of parse errors.
Comment 2 Julian Reschke 2010-02-17 22:07:27 UTC
The "WEBADDDRESS" spec requires that parsing "fails" for:

  http://a[b].example.org/


"If w doesn't match the <URI-reference> production, even after the above changes are made to it, then parsing the Web address fails with an error. [RFC3986]"

(see http://www.w3.org/html/wg/href/draft, Section 2, Step 6)
Comment 3 Ian 'Hixie' Hickson 2010-02-17 22:27:04 UTC
Yes, I know, I basically wrote that text. What concrete case doesn't handle this?
Comment 4 Julian Reschke 2010-02-18 07:40:45 UTC
How many times do I need to repeat it?

The case is 

    http://a[b].example.org/

which, as far as I can tell, doesn't parse according to that spec.

Comment 5 Ian 'Hixie' Hickson 2010-02-18 07:43:28 UTC
If you're only asking about parsing, then there's no expected behaviour. The parsing fails. That also happens to be out of scope for HTML5 now, so I don't really know why you're asking me. There's no HTML in the example you gave, nor is there any DOM manipulation, or any XHTML, or anything that HTML gives any conformance criteria for.

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Did Not Understand Request
Change Description: no spec change
Rationale: The question appears to be meaningless.
Comment 6 Maciej Stachowiak 2010-02-18 08:12:36 UTC
Here is a test case that I believe expresses Julian's intent:

<a id="link" href="http://a[b].example.org/">Some link</a>
<pre>
<script>
var link = document.getElementById("link");
document.writeln(link.protocol);
document.writeln(link.hostname);
document.writeln(link.pathname);
</script>
</pre>

I think Julian wants it to be defined what this outputs. The results do not match among Safari, Opera, Firefox and Chrome. (The first two and the last two match each other.)  Per WEBADDRESSES, the parsing in this case "fails with an error", and it does not say what the components are. HTML5 just uses the components returned by WEBADDRESSES, and does not handle the "failed with an error" case. Seems like one of the two needs to change.
Comment 7 Maciej Stachowiak 2010-02-18 08:13:48 UTC
Reopened per new information. (Hope that's ok, Julian.)
Comment 8 Julian Reschke 2010-02-18 08:15:39 UTC
(In reply to comment #7)
> Reopened per new information. (Hope that's ok, Julian.)

Appreciated; although I don't think this is "new" information. It would be cool if your mediation wasn't needed here.
Comment 9 Anne 2010-02-18 08:19:06 UTC
I think this is a bug in the URL spec by the way. When it says that parsing fails it should also say what each of the components are.
Comment 10 Ian 'Hixie' Hickson 2010-02-18 08:26:34 UTC
(In reply to comment #6)
> Here is a test case that I believe expresses Julian's intent:
> 
> <a id="link" href="http://a[b].example.org/">Some link</a>
> <pre>
> <script>
> var link = document.getElementById("link");
> document.writeln(link.protocol);
> document.writeln(link.hostname);
> document.writeln(link.pathname);
> </script>
> </pre>

That case is already defined. The spec says that it should write three empty strings. See the paragraph starting "On getting, if the input is an absolute URL" and ending "Otherwise, the attribute must return the empty string." in the Interfaces for URL manipulation section.

(In reply to comment #8)
> 
> Appreciated; although I don't think this is "new" information.

It's new because it gives an actual case, unlike your report, which did not give enough information to determine the validity of the report.

(In reply to comment #9)
> I think this is a bug in the URL spec by the way. When it says that parsing
> fails it should also say what each of the components are.

There is no time as far as I am aware where the components are used if parsing fails. If there was such a time, that would be a valid bug.


EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: see above - there's no bug here
Comment 11 Maciej Stachowiak 2010-02-18 08:30:02 UTC
It appears I was mistaken. I agree that the spec does define this case (because a string is an "absolute URL" as defined in the spec if and only if parsing it succeeds.)
Comment 12 Julian Reschke 2010-02-18 09:06:05 UTC
(In reply to comment #11)
> It appears I was mistaken. I agree that the spec does define this case (because
> a string is an "absolute URL" as defined in the spec if and only if parsing it
> succeeds.)

What confused me here is that "absolute URL" is *not* defined to be a URL that happens to be absolute, but comes with additional constraints. Not sure that this is a good idea; and also I'm very sure that we wouldn't want to use that terminology in IRIbis.
Comment 13 Maciej Stachowiak 2010-02-18 09:20:46 UTC
(In reply to comment #12)
> (In reply to comment #11)
> > It appears I was mistaken. I agree that the spec does define this case (because
> > a string is an "absolute URL" as defined in the spec if and only if parsing it
> > succeeds.)
> 
> What confused me here is that "absolute URL" is *not* defined to be a URL that
> happens to be absolute, but comes with additional constraints. Not sure that
> this is a good idea; and also I'm very sure that we wouldn't want to use that
> terminology in IRIbis.
> 

The way the spec arranged things initially confused me and Anne too, though only because we didn't notice the "if the input is an absolute URL" bits. I could imagine IRIbis exposing an interface that makes this more clear.
Comment 14 Ian 'Hixie' Hickson 2010-02-18 09:22:36 UTC
I just realised why I couldn't work out what Julian was talking about. I didn't see the bug's summary, which contained critical information.