You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
HEAD doesn't set right Content-Type or right Content-Length headers #454
for example GET request to foo.png includes correct header Content-Type: image/png
but HEAD request to foo.png responds with incorrect header Content-Type: text/plain; charset=utf-8
Grumble. The bad content-length makes checking that JS library files are the right ones more difficult. It is basic HTTP that headers on HEAD MUST be exactly the ones you would get with GET
timbl added the priority label on Feb 21, 2017
changed the title [-]HEAD doesn't set Content-Type based on file extension[/-][+]HEAD doesn't set right Content-Type or right Content-Length headers[/+]on Feb 27, 2018
So, this is really two issues, Content-Type, which is a really nasty bug, but something @megoth has not been able to reproduce, and secondly Content-Length, which should be implemented by a standalone module in the architecture. I think we should split this into two issues.
Hmmm, or it should be a bug on that HEAD isn't identical to GET headers, which is also just really weird that the framework doesn't do right out of the box.
If you ask me, we can just have the exact same logic, except we don't write a body (so catch all res.end/write calls or pipes to it). That should do for now; optimizations always possible later.
This should be part of the HTTP stack of the server environment
Yes, but we're playing server on a very low level here. I think it is good that the Solid server takes ownership of the HTTP methods; node-solid-server does not do so with the right architecture unfortunately.
sure, but a reasonable architecture does it in middleware, so that the server behaves HTTP compliant by default, you'd actually have to break it on purpose to break it... And you should only have to modify the behavior that needs to adapted, not all the other things.
I only reported (two years ago) the issue on Content-Type which afterwards also was reported in #632 and #789 I think one of the maintainers added the Content-Length part here.
$ curl -i -H "Accept: text/turtle" -X HEAD https://localhost:8443/public/ | grep -i "content-type"
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 2 0 0 0 0 0 0 --:--:-- 0:00:04 --:--:-- 0curl: (56) SSLRead() return error -9806
Content-Type: application/octet-stream; charset=utf-8
Note also the curl: (56) SSLRead() return error -9806 - I don't know if that's relevant. For comparison, the same with GET:
$ curl -i -H "Accept: text/turtle" -X GET https://localhost:8443/public/ | grep -i "content-type"
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 778 0 778 0 0 11502 0 --:--:-- --:--:-- --:--:-- 11611
Content-Type: text/turtle
Also, no SSLRead error in this case.
Server console log shows:
Solid server (5.0.0-beta.7) running on https://localhost:8443/
and for HEAD:
solid:get /public/ on localhost +0ms
solid:get HEAD only +0ms
and for GET:
solid:get /public/ on localhost +0ms
solid:handlers GET -- Reading directory +2ms
solid:handlers Files in directory: .acl,dcd0fc80-test_workset,test_workset +0ms
$ curl -iIk https://csarven.localhost:8443/profile/card | grep -iE "content-(type|length):"
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 2 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
Content-Type: text/turtle; charset=utf-8
Content-Length: 2
$ curl -ik https://csarven.localhost:8443/profile/card | grep -iE "content-(type|length):"
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 1612 0 1612 0 0 34419 0 --:--:-- --:--:-- --:--:-- 35043
Content-Type: text/turtle
Seems charset and Content-Length are missing for GET.
Perhaps the following may some insight:
$ curl -ikH'Accept: text/html' https://csarven.localhost:8443/profile/card | grep -iE "content-(type|length):"
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 518 100 518 0 0 10941 0 --:--:-- --:--:-- --:--:-- 11021
Content-Type: text/html; charset=utf-8
Content-Length: 518
$ curl -iIkH'Accept: text/html' https://csarven.localhost:8443/profile/card | grep -iE "content-(type|length):"
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 2 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
Content-Type: text/turtle; charset=utf-8
Content-Length: 2
(This is besides the fact that NSS awkwardly generates an HTML representation for "SolidOS Web App", which has nothing to do with even being vaguely equivalent to a WebID Profile Document!)
Seems to produce charset for text/html media type.
Activity
dmitrizagidulin commentedon Nov 22, 2016
Interesting.. thanks for reporting this!
dmitrizagidulin commentedon Feb 21, 2017
Also address setting the correct
Content-Lengthheader on HEAD requests.timbl commentedon Feb 21, 2017
About time this serious breakage of the HTTP protocol was fixed
timbl commentedon Feb 27, 2018
Grumble. The bad content-length makes checking that JS library files are the right ones more difficult. It is basic HTTP that headers on HEAD MUST be exactly the ones you would get with GET
timbl added the priority label on Feb 21, 2017
[-]HEAD doesn't set Content-Type based on file extension[/-][+]HEAD doesn't set right Content-Type or right Content-Length headers[/+]RubenVerborgh commentedon Jul 19, 2018
Might be fixed with #662.
6 remaining items
kjetilk commentedon Oct 2, 2018
So, this is really two issues,
Content-Type, which is a really nasty bug, but something @megoth has not been able to reproduce, and secondlyContent-Length, which should be implemented by a standalone module in the architecture. I think we should split this into two issues.kjetilk commentedon Oct 2, 2018
Hmmm, or it should be a bug on that
HEADisn't identical toGETheaders, which is also just really weird that the framework doesn't do right out of the box.megoth commentedon Oct 2, 2018
Yes, once again I didn't quite get the task =P I've been able to reproduce the bug now, and will continue on it.
RubenVerborgh commentedon Oct 2, 2018
If you ask me, we can just have the exact same logic, except we don't write a body (so catch all
res.end/writecalls orpipes to it). That should do for now; optimizations always possible later.kjetilk commentedon Oct 2, 2018
I'm just baffled this is actually an issue at all... This should be part of the HTTP stack of the server environment, and not the concern of developers. Like it is in the Plack environment, e.g.: https://github.com/kjetilk/RDF-LinkedData/blob/master/script/linked_data.psgi#L52
RubenVerborgh commentedon Oct 2, 2018
Yes, but we're playing server on a very low level here. I think it is good that the Solid server takes ownership of the HTTP methods; node-solid-server does not do so with the right architecture unfortunately.
kjetilk commentedon Oct 2, 2018
sure, but a reasonable architecture does it in middleware, so that the server behaves HTTP compliant by default, you'd actually have to break it on purpose to break it... And you should only have to modify the behavior that needs to adapted, not all the other things.
elf-pavlik commentedon Oct 2, 2018
I only reported (two years ago) the issue on
Content-Typewhich afterwards also was reported in #632 and #789 I think one of the maintainers added theContent-Lengthpart here.elf-pavlik commentedon Oct 2, 2018
I think easiest way to reproduce based on #789
HEAD
curl -I https://rubentest.solidtest.space/profile/card | grep Content-TypeContent-Type: text/plain; charset=utf-8vs
GET
curl -i https://rubentest.solidtest.space/profile/card | grep Content-TypeContent-Type: text/turtlemichielbdejong commentedon Mar 15, 2019
@gklyne is still seeing this issue
gklyne commentedon Mar 15, 2019
Here's a simple example of what I'm seeing:
Note also the
curl: (56) SSLRead() return error -9806- I don't know if that's relevant. For comparison, the same with GET:Also, no SSLRead error in this case.
Server console log shows:
and for HEAD:
and for GET:
(I've elided a lot of
solid:ACLtracing.)CxRes commentedon Apr 7, 2020
I am still seeing this issue in April 2020.
The header in response to
HEADto a container is like this:And in response to a
GET, headers to the same container look like this:As you can clearly see the
content-typeand other things are inconsistent!!!!?????.csarven commentedon Oct 12, 2024
Seems
charsetandContent-Lengthare missing forGET.Perhaps the following may some insight:
(This is besides the fact that NSS awkwardly generates an HTML representation for "SolidOS Web App", which has nothing to do with even being vaguely equivalent to a WebID Profile Document!)
Seems to produce
charsetfortext/htmlmedia type.