Bug Tracker

Opened 6 years ago

Closed 6 years ago

#12950 closed bug (wontfix)

scriptCharset in $.ajax not working

Reported by: xmachac2@… Owned by: xmachac2@…
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

Change History (7)

comment:1 Changed 6 years ago by jaubourg

Owner: set to xmachac2@…
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.

comment:2 Changed 6 years ago by jaubourg

Component: unfiledajax

comment:3 Changed 6 years ago by dmethvin

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?

comment:4 in reply to:  3 Changed 6 years ago by jaubourg

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?

comment:5 Changed 6 years ago by dmethvin

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.

comment:6 Changed 6 years ago by jaubourg

Well you can do like the OP and put crossDomain to true in order to trigger the use of the script transport.

comment:7 Changed 6 years ago by jaubourg

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;
  }
});
Note: See TracTickets for help on using tickets.