Skip to main content

Bug Tracker

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 jaubourg comment:1

owner: → xmachac2@atlas.cz
status: newpending

The documentation is not clear enough: scriptCharset is an option that belongs to the script transport. I don't see this as becoming a general option that would also be used in the xhrtransport. What we could do is automagically set the crossDomain option to true if scriptCharset is given in the script 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.

Changed November 23, 2012 12:37PM UTC by jaubourg comment:2

component: unfiledajax

Changed November 23, 2012 05:23PM UTC by dmethvin 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 jaubourg 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 dmethvin 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 jaubourg 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 jaubourg comment:7

resolution: → wontfix
status: pendingclosed

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;
  }
});