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 21175 - "Last string" of path is undefined if path has no strings while a URL is parsed
Summary: "Last string" of path is undefined if path has no strings while a URL is parsed
Status: RESOLVED FIXED
Alias: None
Product: WHATWG
Classification: Unclassified
Component: URL (show other bugs)
Version: unspecified
Hardware: PC Windows NT
: P2 normal
Target Milestone: Unsorted
Assignee: Anne
QA Contact: sideshowbarker+urlspec
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-03-03 00:59 UTC by Peter Occil
Modified: 2013-03-04 09:45 UTC (History)
1 user (show)

See Also:


Attachments

Description Peter Occil 2013-03-03 00:59:32 UTC
From the parsing algorithm:
----
If buffer is ".." and c is one of EOF code point, "/", and "\", set the last string in url's path to the empty string.

Otherwise, if buffer is "..", remove the last string from url's path.
----

For URLs like:  

http://example.com/../../filename  ,

when there are no strings in the path yet, after the first "../" is read,
it's undefined what happens. Does it trigger an error?  
Does the parser return failure?  Or is that step just simply ignored? 

This may also affect this rule, found elsewhere in the algorithm:
-----

Set url's host to base's host, url's port to base's port, url's path to base's path, then remove url's path's last string, set state to relative path state, and decrease pointer by one.
-----
Comment 1 Anne 2013-03-03 13:17:37 UTC
Yeah, I suppose this should all just become pop url's path and append to url's path, with replace being that combination.
Comment 3 Peter Occil 2013-03-03 15:05:07 UTC
Thanks for your change.  I think having it say "pop url's path if possible" would make it better, to further make it clear.