On Tue, 29 Sep 2009, Matthieu Moy wrote:
Exactly. So curl is not "wrong", it just can't work around this user-error.
It may not want work around user-errors, but you can hardly say that
it _can't_.
It can't work around this error. In theory we could make it GUESS that one of
the @-letters are actually supposed to be %40, but I won't. It could also
guess that @ was accidentally a '2' with alt-gr pressed when using a nordic
keyboard layout. Guessing here is crazy.
Many tools do in this case, Firefox is one of them.
So what if you had that @ in your password and not in your user name?
And anyway, trying to connect to email.com@xxxxxxxxxx is probably the worst
thing it can do.
I understand that you're saying that as a git user and someone who's not into
curl and libcurl details, but I'm in the opposite corner mostly and I claim
that isn't at all such a bad outcome from that input. curl has that approach
through-out its entire URL parser. It gets what it needs and then uses the
rest unparsed. That way it is very liberal in what it accepts and it doesn't
reject bad URLs as long as it only can extract the parts it needs.
If curl had a strict parser it would of course bluntly reject that URL at
once.
At least, it could warn about two @ in the URL and say it can't handle it
It could, sure. But curl has no such strict parser so it accepts all sorts of
various violations.
I don't think this is the proper place to discuss what curl (or libcurl)
should or shouldn't do with given URLs - but you're most welcome to bring your
ideas and patches to the curl project and we can debate their virtues over
there.
--
/ daniel.haxx.se
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html