Hi Gregory,
What you've mentioned is indeed the intended behaviour.
* Gregory R Fellow [181001 08:55]:
> Hi. Is it the intended behavior for wget to allow sending custom header
> lines with no value?
>
>
> The following clears previous user-defined headers as described in the
> documentation:
> --header=
Yes, as you've correctly mentioned, this case is mentioned in the documentation
as a way to remove any previously defined headers.
>
> The following both send a header with no value:
> --header="Accept-Encoding:"
> --header="Accept-Encoding: "
>
These are both accepted by Wget and they will send the exact same HTTP request.
This is because, both of them are considered equivalent _and_ valid according
to the HTTP/1.1 Spec in RFC 7230. The spec clearly mentions that a leading
whitespace is okay and so is an empty Header value.
>
> This gets an "Invalid header" error from wget:
> --header="Accept-Encoding"
Of course. Because it is an invalid header according to the HTTP spec :). Per
RFC 7230, a header _must_ have the form: ": ". The
colon being immediately after the header-name is a hard requirement.
>
> I noticed this behavior while trying to disable some of wget's automatically
> generated headers (which apparently isn't possible except for User-Agent via
> --user-agent=).
In Wget, you can't disable the headers, but you can indeed overwrite them to
something else or even make them empty. The real question here is, why do you
want to disable some headers? Since Wget only generated headers that are
absolutely necessary for parsing the request correctly.
>
> Thanks in advance for your help.
>
> Greg
>
>
>
--
Thanking You,
Darshit Shah
PGP Fingerprint: 7845 120B 07CB D8D6 ECE5 FF2B 2A17 43ED A91A 35B6
signature.asc
Description: PGP signature
