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 27280 - Query state and < 0x20 code points
Summary: Query state and < 0x20 code points
Status: RESOLVED FIXED
Alias: None
Product: WHATWG
Classification: Unclassified
Component: URL (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: Unsorted
Assignee: Anne
QA Contact: sideshowbarker+urlspec
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-11-08 08:43 UTC by Anne
Modified: 2015-06-16 10:21 UTC (History)
2 users (show)

See Also:

Attachments

Description Anne 2014-11-08 08:43:38 UTC 
I noticed something strange writing tests for iso-2022-jp (not uploaded yet).

If I had a url like

  https://example.com/?\0x0E\0x0F\0x1B

it would come out as (looking at .search anyway)

  https://example.com/?

but if I had a trailing "s" it would come out as

  https://example.com/?%0E%0F\x1Bs

which together demonstrates two bugs in the specification algorithm, if we want to align with Gecko, Safari, and Chrome here.
Comment 1 Anne 2014-11-08 14:34:04 UTC 
I realized this might actually be a side effect of initial stripping of code points around a URL before parsing, since I was using the <a> element.

That seems far more likely the thing that needs investigation and whether all URL parsing contexts need to share that.