-
Bug
-
Resolution: Done
-
Major
-
2.0.15.Final
-
None
DefaultServlet does not set Content-Type HTTP header in response for the directory resource when directory-listing feature is enabled.
As browsers apparently try to guess appropriate Content-Type of the downloaded resource, this problem is not spotted unless in combination with X-Content-Type-Options header is present in the HTTP response too. This header effectively discourages browser to guess the Content-Type of the resource.
Output for directory-listing request in attached reproducer [^helloworld-html5.war]:
$ curl -v http://127.0.0.1:8080/helloworld-html5/css/ >/dev/null
* Trying 127.0.0.1...
* TCP_NODELAY set
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Connected to 127.0.0.1 (127.0.0.1) port 8080 (#0)
> GET /helloworld-html5/css/ HTTP/1.1
> Host: 127.0.0.1:8080
> User-Agent: curl/7.59.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Connection: keep-alive
< Content-Length: 824
< Date: Fri, 04 Jan 2019 14:32:46 GMT
<
{ [824 bytes data]
100 824 100 824 0 0 804k 0 --:--:-- --:--:-- --:--:-- 804k
* Connection #0 to host 127.0.0.1 left intact
Notice that there is no Content-Type header in HTTP response.
- is cloned by
-
WFLY-11558 Content-Type header is not set in HTTP response for directory resource in servlet directory-listing feature
- Closed