Can not change/remove the "accept-ranges" response header

[jasonswearingen]

I thought this was a h2o2 proxy issue (see here: hapijs/h2o2#21 ) but I just repro'd this on normal Hapi.

if I have the following route, the accept-ranges response header is set and I cannot modify it, even if the onPreResponse ext point.

[jasonswearingen]

a fuller repro, the accept-ranges:bytes response header is always set in the following example.

        server.ext("onPreResponse", function (request, reply) {
            if (request.response != null && request.response.header != null) {
                request.response.header("accept-ranges", "none!!");
            }
            reply.continue();
        });

        server.route({
            method: "GET",
            path: "/api/test",
            handler: (request, reply) => {
                var tmpStr = "asdf";
                for (var i = 0; i < 10; i++) {
                    tmpStr += tmpStr;
                }
                var response = reply(tmpStr);
                //response.type("application/pdf");
                response.header("content-encoding", "base64");
                response.header("content-type", "application/pdf");
                response.header("accept-ranges", "none");
            },
        });

I need to disable accept-ranges so that Chrome doesn't spam multiple requests for my api. (it tries to load 1 page of a pdf at a time)

[jasonswearingen]

looks like a bug:

hapi/lib/transmit.js

Line 248 in d34f0de

response._header('accept-ranges', 'bytes');

I think that line should check if accept-ranges is already set, and if not, set it.... though I also suppose the code section above that line (transmitting requested ranges) needs to be handled too.

[jasonswearingen]

FYI, my current workaround is to return status-code 207 for non-text GET requests.

Also FYI, when I was troubleshooting the problems with chrome, this is the post I found that explained the problem with accept-ranges. http://stackoverflow.com/questions/1817750/do-most-browsers-make-multiple-http-requests-when-displaying-a-pdf-from-within-t

[jasonswearingen]

My statusCode:207 workaround doesn't work because while chrome load+render of the pdf works, it errors when trying to save the pdf (seems like a chrome bug)

So my new workaround is to force gzip encoding of pdfs, (and back to returning statusCode:200)

I guess in my circumstance that's not bad anyway, I save about 10% in bandwidth this way.

[kanongil]

I'd say that it is a bug that it is impossible to not send the accept-ranges header.

FYI, you might be able to disable the header by removing the content-length header in an onPreResponse hook.