Question - json()'s benefit of converting to Blob about fetch-client HOT 17 CLOSED

Or I wonder if that changed recently?

It's been this way since we first started developing with Aurelia, which was April 2016.

Thanks for the response though!

If I understand you correctly, I think I would rather have the aurelia-fetch-client specify the content-type manually than have to lose out on the convenience of being able to inspect POST bodies in Chrome devtools.

from fetch-client.

One thing I've just discovered after updating to 1.3.3 is that this change breaks things if you specify default headers in your HttpClient without specifying content type.

So when I log in, I add an authentication header to my HttpClient:

     this.http.configure(config => {
         config.withDefaults({
             headers: {
                 'Authorization': 'Bearer ' + this.token,
             }
         });
     });

Looking at the code it looks like you've accommodated the fact that json() no longer adds a content-type header by setting the content-type header in the defaults, but now when I change the defaults I've gotta remember to do that too:

     this.http.configure(config => {
         config.withDefaults({
             headers: {
                 'Authorization': 'Bearer ' + this.token,
                 'Content-Type': 'application/json',
             }
         });
     });

Not a huge deal but maybe worth documenting somewhere.

from fetch-client.

The blob json is not friendly to beginner. We should change this. Or at least add another api and promote it instead

from fetch-client.

@m-andrew-albright Thank this person who brought it to my attention on reddit: https://www.reddit.com/r/javascript/comments/7qrxqd/building_the_perfect_masterdetail_page_in_aurelia/dssuqlj/

from fetch-client.

@bryanrsmith may be able to comment on this.

from fetch-client.

The benefit of using a Blob is that the Request adopts the content-type of the Blob, so you get content-type: application/json on the request without having to manually specify it. I wasn't aware that it caused the body to be hidden in dev tools, and I'm a little surprised I didn't notice :-). Or I wonder if that changed recently?

from fetch-client.

@EisenbergEffect @bryanrsmith do we want to change this? I think we want to change this.

from fetch-client.

An OPTIONS request is just a request asking permission to make the request. The browser automatically makes this request whenever it needs permissions to make a CORS request. If you were not getting the OPTIONS request before, that was a bug.

If you're getting an error at the OPTIONS request, make sure your CORS are properly configured. Otherwise, after the OPTIONS completes, your POST will continue normally.

from fetch-client.

@davismj It was indeed an issue on the server side of things. Cheers for your help!

from fetch-client.

These changes actually break my previously working multipart-upload.

fileMultipartUpload = (file: File, data:any) => { 
    // Upload image
    let formData = new FormData();
    formData.append("file", file);
    this.http.fetch('../'+this.fileUploadResource+this.fileUploadParameters, {
        method: 'post',
        body: formData
    });
};

Up to now the Content-Type was automatically set (I guess by the browser?), as well as the boundary for the FormData. Is there any quick solution to this?

from fetch-client.

@itfourp downgrade for now, let me see if i can't jump back on and get a more robust solution in place tomorrow.

@EisenbergEffect @bigopon
Perhaps we continue returning a blob from the json() helper and read the json out of the blob when building the request? The only problem with this strategy is you have to create a FileReader to read text from a blob and it starts to get complicated.

from fetch-client.

Thanks for the feedback all, I'm looking at fixing this right now.

from fetch-client.

@mabster Did you find a solution to this? I have the exact same issue after updating from 1.2.0 to 1.3.1. Also some of my POST requests are suddenly OPTIONS requests instead :/

from fetch-client.

I for one am glad to no longer need to open Fiddler every time I want to get a quick view of my POST payload. Thanks for making this change, @davismj

from fetch-client.

@davismj Ok, but this wasn't an issue before with the previous version. The requests are being made on the same domain (but different subdomains) - does that change anything? Is there a simple fix or should I stick with 1.2.0? I noticed that adding 'content-type': 'application/json' to my requests in 1.2.0 produces the same issue as I have without content-type on 1.3.1

from fetch-client.

Yes, subdomains and different ports will trigger the browser to send the preflight OPTIONS request.

That is correct, because this new change automatically sets that header.

You're going to want to have your server accept the content-type header. https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Headers

Unfortunately, I think I've boxed you in a bit here. We could start adding flags to tell the fetch client not to add the content-type header. However, that would be a very awkward change as a large share of servers will try to parse your request as xml or www-form-urlencoded if you don't specify the content-type. In general, you're going to want to have the header set, and so in general, you're going to want to accept the header.

The reason we didn't need it before was because we had leveraged some relatively new behavior that had unfortunate side effects. The fact that the above header didn't need to be set should actually be considered one of those side effects.

from fetch-client.

@davismj Ah ok, thanks! I'm sure we'll find a solution then. I'll do some digging.

from fetch-client.