Read custom headers from HTTP response in Elm

Question

I am using Http.expectStringResponse to pass the HTTP response metadata along with the body (or error). And I log the Dict.keys metadata.headers into the console. According to log, Elm does not pass all the headers. As seen from the attached image, the set of headers in the dev-tools network tab is a superset of the headers in the log. I cannot find explanation to this in the docs. Hopefully Elm community can shed some light.

Update

As pointed out by glennsl and Gareth Latty, this is CORS related and has nothing to do with Elm. XMLHttpRequest produces same result.

Answer 1

I can't reproduce this. There are some headers that won't be returned—specifically Set-Cookie and Set-Cookie2, but all the ones in your example should be, at least as far as Elm is concerned.

You can see the implementation for Http's header parsing:

_Http_parseHeaders(xhr.getAllResponseHeaders())

...

function _Http_parseHeaders(rawHeaders)
{
    if (!rawHeaders)
    {
        return __Dict_empty;
    }

    var headers = __Dict_empty;
    var headerPairs = rawHeaders.split('\r\n');
    for (var i = headerPairs.length; i--; )
    {
        var headerPair = headerPairs[i];
        var index = headerPair.indexOf(': ');
        if (index > 0)
        {
            var key = headerPair.substring(0, index);
            var value = headerPair.substring(index + 2);

            headers = A3(__Dict_update, key, function(oldValue) {
                return __Maybe_Just(__Maybe_isJust(oldValue)
                    ? value + ', ' + oldValue.a
                    : value
                );
            }, headers);
        }
    }
    return headers;
}

You can see in Elm, no filtering is happening.

getAllResponseHeaders() does filter the two previously mentioned headers:

A ByteString representing all of the response's headers (except those whose field name is Set-Cookie or Set-Cookie2) separated by CRLF, or null if no response has been received. If a network error happened, an empty string is returned.

As you are seeing this, it is likely something specific to the situation causing the browser not to return all the headers. We would need more information (ideally an example where we can reproduce the issue) to say more. As suggested in glennsl's comment, it seems likely this might be a CORS issue. I would suggest trying using getAllResponsHeaders() directly in that environment and removing Elm from the equation.