-
Notifications
You must be signed in to change notification settings - Fork 38
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
elinks does not seem to send Accept header. #143
Comments
AFAIR elinks sent |
On 2022-04-20 at 02:28 -0700, rkd77 ***@***.***> wrote:
AFAIR elinks sent Accept: */*
Now it is configurable. You can set protocol.http.accept arbitrarily.
Great! Could the default be something more specific than */*. It was very
difficult for me to find out what the problem with these sites was, and I'm a
developer. For people with less experience this kind of troubleshooting might
be impossible.
…--
Aura
|
I don't know what to set as default. No changes seems good policy here. |
Endpoints that can give web pages or API responses will be increasingly common. There's a weighting factor available in the header. Perhaps a good default would be:
these priority specifications are at least in the 1.0 and 1.1 specs |
ok, let it be: text/html, text/*;q=0.9, /;q=0.8 |
Some sites can return different data with the same request URL depending on the Accept header sent by the client.
For example hackage.haskell.org and crates.io currently return application/json data, unless text/html is explicitly requested. If elinks asked for text/html these sites would function more like they should. There are most likely some other sites which work this way.
lynx seems to send this header.
The text was updated successfully, but these errors were encountered: