Caddy: CORS options preflight contains payload in body

[jpambrun]

I am no HTTP expert so bear with me..

1. What version of Caddy are you running (caddy -version)?

commit b149a86bc2a3fcbdec55ac1fb3e2e757adcb658e

2. What are you trying to do?

Use byte range requests for streaming from another origin.

3. What is your entire Caddyfile?

https://jpx.jfpb.net {
        root /home/jpambrun/www_jpx
        ext  .html
        header / Access-Control-Allow-Origin  *
        header / Access-Control-Request-Headers  *
        header / Access-Control-Allow-Methods  *
        header / Access-Control-Allow-Headers  "Range"
}

4. How did you run Caddy (give the full command and describe the execution environment)?

./caddy

5. What did you expect to see?

For each byte range requests from another origin, chrome issues two requests: one preflight OPTIONS and one GET. I expect the first one to have no message body and the second one to have the requested byte range.

6. What did you see instead (give full error messages and/or log)?

The first OPTIONS response contains the full file in the message body and the second GET response contains the partial byte-range stream.

[mholt]

Can you please share your request(s) as well so we can try them? And maybe how you're forming the request with JS in case we need to repro in Chrome.

[jpambrun]

The request is formed here :
https://github.com/jpambrun/dcmj2k-streaming-viewer/blob/master/src/js/dcmdlworker.js#L79

The OPTIONS preflight request:

:authority:jpx.jfpb.net
:method:OPTIONS
:path:/data/000000.dcm
:scheme:https
accept:*/*
accept-encoding:gzip, deflate, sdch
accept-language:en-US,en;q=0.8,fr-CA;q=0.6,fr;q=0.4
access-control-request-headers:range
access-control-request-method:GET
cache-control:no-cache
dnt:1
origin:http://localhost:8000
pragma:no-cache
referer:http://localhost:8000/?worker=1
user-agent:Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.112 Safari/537.36

Response:

accept-ranges:bytes
access-control-allow-headers:Range
access-control-allow-methods:*
access-control-allow-origin:*
access-control-request-headers:*
content-length:184586
content-type:application/dicom
date:Wed, 13 Apr 2016 17:48:14 GMT
etag:W/"554a7f64-2d10a"
last-modified:Wed, 06 May 2015 20:53:56 GMT
server:Caddy
status:200
Request Headers

The GET request:

:authority:jpx.jfpb.net
:method:GET
:path:/data/000000.dcm
:scheme:https
accept:*/*
accept-encoding:gzip, deflate, sdch
accept-language:en-US,en;q=0.8,fr-CA;q=0.6,fr;q=0.4
cache-control:no-cache
dnt:1
origin:http://localhost:8000
pragma:no-cache
range:bytes=0-34999
referer:http://localhost:8000/js/dcmdlworker.js
user-agent:Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.112 Safari/537.36

Response:

accept-ranges:bytes
access-control-allow-headers:Range
access-control-allow-methods:*
access-control-allow-origin:*
access-control-request-headers:*
content-length:35000
content-range:bytes 0-34999/184586
content-type:application/dicom
date:Wed, 13 Apr 2016 17:48:14 GMT
etag:W/"554a7f64-2d10a"
last-modified:Wed, 06 May 2015 20:53:56 GMT
server:Caddy
status:206

[wmark]

This is due to us calling ServeContent here:

https://github.com/mholt/caddy/blob/93d982a5a4c2bfc75f8d31bee101f00a0c746518/middleware/fileserver.go#L138

… and Go only checking for HEAD:

https://github.com/golang/go/blob/9b67a5de79af56541c48c95c6d7ddc8630e1d0dc/src/net/http/fs.go#L261

[elcore]

Hello @jpambrun,

just some improvements :smile:

https://jpx.jfpb.net {
        root /home/jpambrun/www_jpx
        ext  .html
        header / {
                Access-Control-Allow-Origin  *
                Access-Control-Request-Headers  *
                Access-Control-Allow-Methods  *
                Access-Control-Allow-Headers  "Range"
        }
}

[captncraig]

There is a special plugin to handle cors natively. https://caddyserver.com/docs/cors. It properly short-circuits the options request and returns a 200 with no payload.

Perhaps that would make this easier for you.

[mholt]

Been looking into this, consulting with some other devs. We may be able to handle this natively in the file server by checking for that method. OPTIONS responses are allowed to have a response body, but I can't think of any good reason why a static file server would need to send one in an OPTIONS response.

[elcore]

@mholt

but I can't think of any good reason why a static file server would need to send one in an OPTIONS response.

Me too, it´s just a file server

[wmark]

While debugging a different plugin I've learned that _browse_ is sending nonsense for POST and PUT.

Point is, the only methods _browse_ expects, and has well-defined answers for, are currently GET and HEAD. Therefore all other methods will return a »method not allowed« beginning with 4e98cc3005269cd0a4f88cb0af8349f141bdb0a0 to prevent further unexpected server responses. That is, until anyone decides to extend _browse_ accordingly.