[jboss-jira] [JBoss JIRA] (WFLY-11558) Content-Type header is not set in HTTP response for directory resource in servlet directory-listing feature

[Jan Stourac (Jira)]

     [ https://issues.jboss.org/browse/WFLY-11558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Stourac updated WFLY-11558:
-------------------------------
    Description: 
[DefaultServlet|https://github.com/undertow-io/undertow/blob/master/servlet/src/main/java/io/undertow/servlet/handlers/DefaultServlet.java#L186] 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|https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/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]:
{code}
$ 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
{code}

  was:
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|https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/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]:
{code}
$ 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
{code}



> Content-Type header is not set in HTTP response for directory resource in servlet directory-listing feature
> -----------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-11558
>                 URL: https://issues.jboss.org/browse/WFLY-11558
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 15.0.0.Final
>            Reporter: Jan Stourac
>            Assignee: Stuart Douglas
>            Priority: Major
>         Attachments: helloworld-html5.war
>
>
> [DefaultServlet|https://github.com/undertow-io/undertow/blob/master/servlet/src/main/java/io/undertow/servlet/handlers/DefaultServlet.java#L186] 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|https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/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]:
> {code}
> $ 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
> {code}



--
This message was sent by Atlassian Jira
(v7.12.1#712002)