On Tue, 30 Oct 2012, Simon Pieters wrote:
> On Fri, 26 Oct 2012 17:23:53 +0300, Anne van Kesteren
> wrote:
> >
> > Currently encoding the query component of a URL using the document's
> > encoding affects all URLs with a "relative scheme" (http/ws/file/...).
> > Should we restrict this to http/
On Tue, Oct 30, 2012 at 5:51 PM, Boris Zbarsky wrote:
> I would not be opposed to us explicitly specifying things this way. That
> would incidentally require specs to say exactly when some non-UTF8 encoding
> is supposed to be used for their URIs and what that encoding should be,
> which seems lik
On 10/30/12 11:43 AM, Simon Pieters wrote:
The above applies to what gets sent over the wire when using the
WebSocket(...) constructor. For , the results are different:
http://simon.html5.org/test/url/url-encoding.html
I don't have an opinion at this point about what to do here.
In Gecko, at
On Tue, 30 Oct 2012 17:20:33 +0200, Simon Pieters wrote:
On Fri, 26 Oct 2012 17:23:53 +0300, Anne van Kesteren
wrote:
Currently encoding the query component of a URL using the document's
encoding affects all URLs with a "relative scheme" (http/ws/file/...).
Should we restrict this to http/
On Fri, 26 Oct 2012 17:23:53 +0300, Anne van Kesteren
wrote:
Currently encoding the query component of a URL using the document's
encoding affects all URLs with a "relative scheme" (http/ws/file/...).
Should we restrict this to http/https/file so new schemes such as
ws/wss and others will not
Currently encoding the query component of a URL using the document's
encoding affects all URLs with a "relative scheme" (http/ws/file/...).
Should we restrict this to http/https/file so new schemes such as
ws/wss and others will not be affected by this weird legacy quirk? Is
that something implemen
