Hi,

While working on adding editor support for the new watch file format, I
ran into the `hrefdecode` field.

Its description states that it will perform a URL decode and implies it
is used for "obfuscated" web sites. I do not remember any modern use of
URL encoding as being an obfuscation. If anything, I was surprised that
`uscan` would not do proper URL decoding if needed.

So I checked codesearch.d.n to see if the option was used at all. Turns
out we have a *single* instance of it being used in lighthttpd. The
lighthttpd upstream uses `~` in their pre-release (such as
1.4.56~rc5.tar.xz) of their versions and only the `~` character appears
to be URL encoded (the page appears to be an auto-generated web server
directory index -
https://download.lighttpd.net/lighttpd/releases-1.4.x/). That is, it is
not an obfuscation at all.


So at this point, it feels more like this option is only to have `uscan`
follow standard HTML/URL semantics rather than anything else. I would
recommend that we remove the field and instead unconditionally URL
decode when needed.

I would see version=4 being the last version to support this as an
option with the field never appearing in Version: 5. In my view, it
would save us the mental burden for everyone (consumers and devscripts
maintainers) and we simplify the code path. Whether version=4 should
retroactively apply `hrefdecode`, I am personally in favor of doing so
since no valid version or filename will contain & anyway.
   But I am open to the conservative approach as in my understanding
only `lighthttpd` would be affected in practice and it already has the
option.

Best regards,
Niels

PS: If we decide to keep the `hrefdecode` option for some reason, the
documentation for it is currently botched (using `version=4` syntax
rather than `Version: 5` syntax in debian-watch.5).

FWIW The Debian maintainer of lighttpd is also the upstream author.

I don't they rely on uscan to know a new release has just been published.

Greetings