> 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$ wget 'http://example.com/a b'
> 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.
--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
I think the person doing the work has the prerogative to do it wherever he
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.
or she wants to do it. Maybe the IETF should consider why Anne isn't doing
it in the IETF.
Consensus isn't a value I hold highly, but review of Anne's work is
> > 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.
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. `._.-(,_..'--(,_..'`-.;.'