Vue-resource: support lowercase response content-type

[atian25]

https://github.com/vuejs/vue-resource/blob/master/src/http/interceptor/body.js#L25

    next((response) => {

        var contentType = response.headers['Content-Type'];

        if (isString(contentType) && contentType.indexOf('application/json') === 0) {

[nirazul]

Came here to report the very same bug. I call that coincidence!

[juukie]

I can confirm this bug. In Chrome, response won't be transformed to json because response.headers['Content-Type'] = null.
response.headers['content-type'] = application/json.

[Jigsaw5279]

In the meantime, you can solve it like this:

https://github.com/vuejs/vue-resource/issues/314

[decademoon]

Since HTTP header field names are case-insensitive, maybe it would be best to lowercase all the keys of Response.headers object? If this breaks for anyone, then their code is non-standard.

[bruceman]

We found this bug on latest Chrome, json data be resolved as string not object.

[LinusBorg]

response.json()

[nirazul]

@LinusBorg
Can you elaborate what you mean with your response? In terms of monkey-patching the issue, @Jigsaw5279 has already provided a more versatile and useful solution.

[LinusBorg]

Ignore my comment, I had a misunderstanding.

[danpastori]

Hey Guys,

I'm having the same issue. I wrote a simple interceptor to fix it for the time being if this helps anybody:

Vue.http.interceptors.push((request, next ) => {
    next((response) => {
        if( 'Content-Type' in response.headers 
            && response.headers['Content-Type'] == 'application/json' ){
            if( typeof response.data != 'object' ){
                response.data = JSON.parse( response.data );
            }
        }

        if( 'content-type' in response.headers
            && response.headers['content-type'] == 'application/json' ){
            if( typeof response.data != 'object' ){
                response.data = JSON.parse( response.data );
            }
        }
    });
});

[harrygr]

This too has had me stumped for days! My scripts worked fine via plain Apache but broke when served via CloudFlare, and only on Chrome!

Fix would be much appreciated

[taylorotwell]

Indeed this is broken.

[LinusBorg]

It's already been fixed in the develop branch with this commit

the next release will solve this.

[juukie]

Thanks @LinusBorg!

[LinusBorg]

@steffans fixed it, not me ;)

[juukie]

@LinusBorg thanks for letting us know ;). @steffans thanks for fixing 👍

[ghost]

Is this fixed ? Because i face same problem in [email protected]

[LinusBorg]

Since there was no new release since my last comment:

No, not in a public release (but yes, in the develop branch)

[uxweb]

Hi, how do i install vue-resource develop branch using npm?

Thanks!

[LinusBorg]

you can't. npm does not have the whole repository, only published versions.

you can however clone the repo as a subModule into a folder of your projects repo, checkout the develop branch, build it, and require it from there.

of course, do that at your own risk, the development branch may have bugs, or not even be working at all.

Alternatively/to improve this, you could use npm link to link to a local copy of the vue-resource repo.

Then you can still do require('vue-resource'), as npm_modules/vue-resource will be symlinked to the local repo of vue-resource

[nirazul]

@uxweb @LinusBorg
In fact, you can!

1. Just navigate to the commit you want, for example this one
2. Copy the url and replace commit with tarball
3. Install it normally via npm, for example npm i -D https://github.com/vuejs/vue-resource/tarball/91fefa21faa88bc98271b43adbc23384ba46b93f

Beware: This doesn't work for every module. Just for those that have no complicated npm publish setup and basically push everything from github to npm. But for vue-resource this works.

Beware 2: It's not recommended to use dev branches or random commits for anything more important than trying out stuff or hobby projects. There's a big chance that such intermediary states have errors and/or flaws. After all, there are npm releases for a reason.

[uxweb]

@LinusBorg Thanks!!,

I think is a better idea to include the interceptor proposed by @Jigsaw5279 👌

[alexkb]

Interceptor worked great, thanks! 👍

[rebers]

FIY, just saying

Since HTTP header field names are case-insensitive, maybe it would be best to lowercase all the keys of Response.headers object? If this breaks for anyone, then their code is non-standard.

Is very reckless. There are frameworks out there (e.g. Code Igniter) that do not accept e.g. authorization. This will have indeed broken front-ends all around. Great. 👎