Closed Bug 382019 Opened 18 years ago Closed 17 years ago

URI escaping for web-based protocol handlers does not match spec

Categories

(Core Graveyard :: File Handling, defect)

Product:
Core Graveyard
Component:
File Handling
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
mozilla1.9beta2

People

(Reporter: dmosedale, Assigned: dmosedale)

References

Details

(Whiteboard: [proto])

Need to suggest to WhatWG that instead of defining the URI escaping stuff in the content-handling section, it should be defined elsewhere (perhaps referring to encodeURIComponent). Also need to fix the known-broken code and audit for other lossage, as per the XXX comment in nsWebProtocolRedirect::Run.
Flags: blocking1.9?
Blocks: 380415
No longer blocks: 380415
Depends on: 380415
Blocks: 380415
No longer depends on: 380415
No longer blocks: 380415
Depends on: 380415
Assignee: nobody → dmose
Flags: blocking1.9? → blocking1.9+
Whiteboard: [proto]
Target Milestone: --- → mozilla1.9 M10
Sent mail to the mailing list, after which Hixie and I had the following short conversation in IRC: <Hixie> dmose: the spec was just over-eager. feel free to not escape those characters. i'll log your feedback and change the spec when i next look at that part of the spec. <dmose> Hixie: in that case, it's perhaps worth calling out in the spec that this is, in fact, the escaping done by encodeURIComponent <Hixie> dmose: yeah, that makes sense
One of the patches in bug 394483 will fix this.
Depends on: 394483
No longer depends on: 380415
The first checkin in bug 394483 should have fixed this.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.