Re: [whatwg] New URL Standard from Anne van Kesteren on 2012-09-24 (public-whatwg-archive@w3.org from September 2012)

On Mon, Oct 22, 2012 at 3:35 PM, Ian Hickson <ian@hixie.ch> wrote:

> > The notion that curl, or an HTTP cache manager, or an XML namespace
> > processor, is going to be routing around errors, strikes me on the face
> > of it as being wrong.  One of the main uses I put curl to is making sure
> > I have the URL exactly right before I drop it into chat or whatever.
>
>    $ wget 'http://example.com/a b'
>    --2012-10-23 00:27:43--  http://example.com/a%20b
>
>    # test.cgi returns a 301 with "Location: a b"
>    $ curl -L
> http://damowmow.com/playground/demos/url/in-http-headers/test.cgi
>    This file is:
> http://damowmow.com/playground/demos/url/in-http-headers/a%20b
>
> Software does this stuff already. We need to make sure it does it
> interoperably.
>

Hmm.  I went to tbray.org and made a file at '$ROOT_DIR/tmp/a b' - note the
space.

Then I did

curl -I 'http://www.tbray.org/tmp/a%20b'
curl -I 'http://www.tbray.org/tmp/a b'

Curl, quite properly, doesn’t fuck with what I ask it, and revealed a very
interesting fact: That my Apache httpd returns 200 for both of these, but,
with, uh, interesting variations, amounting to what I think is quite
possibly a bug.  I also pasted the version with the space into the nearest
Web browser, and it quite properly auto-corrected to a%20b.

I think it’s a bug that curl is claiming the 301 pointed at "a%20b" not "a
b".  Because suppose it had pointed at "a%20b" - I don’t want middleware
lying to me.

It seems like a good idea to document the steps by which "a b" pasted in
becomes "a%20b" in the address bar. But I don’t see the relevance outside
human-authored strings.  -T


>
>
> On Tue, 23 Oct 2012, Julian Reschke wrote:
> >
> > This always was about venue, not people. If people want to "fix" or
> > "augment" URIs/IRIs, they should come over to the IETF.
>
> I think the person doing the work has the prerogative to do it wherever he
> or she wants to do it. Maybe the IETF should consider why Anne isn't doing
> it in the IETF.
>
>
> > > The specs don't define everything that implementations have to do to
> > > be interoperable. If the IETF doesn't think that's a problem, then
> > > that's fine, but then y'all shouldn't be surprised when people who
> > > _do_ think that's a problem try and fix it.
> >
> > Yes, please fix *that*, but *just* that without messing with the basics
> > without consensus/review.
>
> Consensus isn't a value I hold highly, but review of Anne's work is
> welcome.
>
> If the IETF community didn't want Anne to do this work, then the IETF
> community should have done it. Having not done it, having not even
> understood that the problem exists, means the IETF has lost the
> credibility it needs to claim that this is in the IETF's domain.
>
> You don't get to claim authority over an area while at the same time
> telling someone else "please fix that" for the hard work that comes with
> that area. The reality is, he who does the hard work, gets the authority.
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>