Let the browser figure out the Content-Type when possible. #80
Conversation
Here's the current algorithm. The first rule that matches is what's used:
* If the user has specified a Content-Type in this.headers, use that.
* If the user has specified a Content-Type in this.contentType, use that.
* If the body of the request is a string, set a Content-Type of
application/x-www-form-urlencoded
* Leave the Content-Type blank so that the browser can handle it.
| @@ -118,7 +118,7 @@ | |||
| */ | |||
| contentType: { | |||
| type: String, | |||
| value: 'application/x-www-form-urlencoded' | |||
| value: null | |||
There was a problem hiding this comment.
There is a (potentially undesired) side-effect of making this null by default: any observer that depends on this value will be called during initialization of the element. For example, _requestOptionsChanged will be called automatically when an iron-ajax instance is created, because null is assigned to this.contentType. See: https://github.com/PolymerElements/iron-ajax/blob/content-type/iron-ajax.html#L267-L270
In the case of iron-ajax, I don't think this will cause a bug immediately, but we have generally avoided default null unless it's really necessary.
Does the value have to be null by default, or will it suffice for it to default to undefined?
There was a problem hiding this comment.
That makes sense, but it looks like it prevents the _requestOptionsChanged observer from firing, because it's waiting for all arguments to be defined. As a result, the tests for auto fail.
There was a problem hiding this comment.
Ah, yes, that's true. I guess null is the best alternative, then.
|
👍 |
Let the browser figure out the Content-Type when possible.
Here's the current algorithm. The first rule that matches is what's used:
application/x-www-form-urlencoded
This way we get correct handling of FormData, XML, etc for free.
Addresses #79 #78 #77 #67 and to some degree #51 and #41