Side navigation
#12950 closed bug (wontfix)
Opened November 23, 2012 08:19AM UTC
Closed November 29, 2012 05:59PM UTC
scriptCharset in $.ajax not working
Reported by: | xmachac2@atlas.cz | Owned by: | xmachac2@atlas.cz |
---|---|---|---|
Priority: | undecided | Milestone: | None |
Component: | ajax | Version: | 1.8.2 |
Keywords: | Cc: | ||
Blocked by: | Blocking: |
Description
Hi,
settings property 'scriptCharset' to any value in ajax Javascript library loading is not working. It's working only with setting crossDomain property to 'true'. In jQuery source
is 'scriptCharset' used only in 'jquery/src/ajax/script.js' file and there is condition 'if (s.crossDomain)' wrapping whole method. We are lazy loading some JS libraries with different chatsets from one domain and crossDomain is therefore unneccessary. Is this bug or correct but with missing documentation on scriptCharset proeprty.
Best regards
Zdenek Machac
Attachments (0)
Change History (7)
Changed November 23, 2012 12:34PM UTC by comment:1
owner: | → xmachac2@atlas.cz |
---|---|
status: | new → pending |
Changed November 23, 2012 12:37PM UTC by comment:2
component: | unfiled → ajax |
---|
Changed November 23, 2012 05:23PM UTC by comment:3
I've always understood scriptCharset
to be used just with the script transport, but I agree it isn't clear from the docs. XHR always assumes content-type is UTF-8 doesn't it? If someone specifies scriptCharset
should that force a script transport for a same-domain request?
Changed November 23, 2012 05:36PM UTC by comment:4
XHR always assumes content-type is UTF-8 doesn't it?
As of XHR2, yes. I seem to remember it assumed the same encoding as the page prior to that... script tags still do.
If someone specifies scriptCharset
should that force a script transport for a same-domain request?
That's exactly the question I have. Shouldn't be really difficult to achieve in the script
prefilter. But isn't this behaviour a bit too magic, even by $.ajax()
's already very laxed standards?
Changed November 23, 2012 05:48PM UTC by comment:5
I have the same concerns about making scriptCharset
magical, and of course it couldn't be used with certain other conflicting options like async: false
. However, without some way to ensure the script transport is being used, most people will resort to something like $("<script/>").attr(...).appendTo("head")
so it's a question if we want to advocate that instead and just document this issue.
Changed November 23, 2012 06:16PM UTC by comment:6
Well you can do like the OP and put crossDomain
to true
in order to trigger the use of the script transport.
Changed November 29, 2012 05:59PM UTC by comment:7
resolution: | → wontfix |
---|---|
status: | pending → closed |
No answer from the OP in a week and two of the team members agree this is an edge case for which a simple workaround exists (force crossDomain
to true
)
If you wanna apply the workaround globally, just use the following prefilter:
$.ajaxPrefilter( "script", function( options ) { if ( options.scriptCharset ) { options.crossDomain = true; } });
The documentation is not clear enough:
scriptCharset
is an option that belongs to thescript
transport. I don't see this as becoming a general option that would also be used in thexhr
transport. What we could do is automagically set thecrossDomain
option to true ifscriptCharset
is given in thescript
prefilter but it seems a little overkill.You should probably report this as a bug in the API documentation: https://github.com/jquery/api.jquery.com
I'll leave the bug as pending to see if other people, including you, have an opinion on this.