-
-
Notifications
You must be signed in to change notification settings - Fork 159
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Configured Resource Content-Type header overwritten by Resource.request() functions #262
Comments
Probably there is a misuse of It's still valid anyway that the current behaviour is different from the hold one and it's up to you decide if this new behaviour is the real behaviour you wanted or not. The thing is that the Resource "Content-Type" value provided by the configuration, got completely overwritten by |
Ok I found your thought here thus I guess we can close this issue. |
Just because I had thoughts doesn’t mean they’re right! I can see a case to be made that the configuration should have precedence, or perhaps that using the default (e.g. I'm looking for something that:
|
I also thought about it. Content-type does make sense to be unique, I guess it’s specified also in the HTTP specs. Regarding the I’m thinking if it would be nice for those two methods to completely hide the There is always the full This anyway will have chance to break devs code due to API signature change |
I found that using the new Siesta 1.4 some network requests are broken.
As short explanation: the Content-Type header, placed by Service configuration, got overwritten by the
Resource.request(...)
methodWhen you use a Resource R1 load using another resource R2 request you end up having the Resource R2 request
Content-Type
overwritten by the requestcontentType
default parameter.Please refer #247 comment for a better explanation
I'm not sure the actual #247 fix is the wanted behaviour and if it is, it will broke quite some code around I guess 😄
The text was updated successfully, but these errors were encountered: