Re: forcing a user@ into the URL if not present

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Johannes Schindelin <johannes.schindelin@xxxxxx> writes:

>>> I haven't seen anybody use such a URL but I would say that is a
>>> natural thing to expect to work, as both username and password are
>>> missing so they should default to some sensible values, in this
>>> case "current user, shouldn't need password", just like
>>> "scheme://site:/" is "port missing so it should default to some
>>> sensible value, appropriate for the scheme".
>
> Yes, that makes total sense to me, too. In fact, I found it rather
> clever once I got over the surprise.

Yup, I'd happily call that "clever" ;-)

> TBH it does not seem overly urgent to add those tests for the HTTPS
> handling. From a cursory look it seems that neither
> transport_helper_init()` nor any code in `remote-curl.c` parses the
> "<user@password>" part of the URL, or for that matter puts
> restrictions on it.

Thanks for checking.
--
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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]