Jeff King <peff@xxxxxxxx> writes: > I think that: > > - we'd never write a raw CR ourselves, as we'd urlencode the character > > - if somebody did put in a raw CR manually like: > > https://example.com\r\n > > then we'd currently fail to match "example.com". Which is probably > not what they wanted. I suspect that \r in a hostname is bogus > anyway (certainly curl will complain about it). I may be misremembering, but an argument I recall against the kind of change we are dicussing now was that we ignore such an entry right now, and the user may have added an entry for the host anew, possibly with a more recent password. Changing the parsing to ignore CR would silently resurrect such a stale entry that the user has written off as unused, and depending on the order of entries in the file, a site that used to work may start failing suddenly. I don't think I'd care too heavily either way. As long as other people will deal with possible backward-incompatibility fallout, I do not mind seeing the change ;-). I still don't see why we need to touch the cache-daemon, though. Thanks.
