Skip to main content

Cannot properly set the Accept HTTP header with jQuery



I'm trying to set the Accept HTTP header to "text/xml" with this jquery code:







$.ajax({

beforeSend: function(req) {

req.setRequestHeader("Accept", "text/xml");

},

type: "GET",

url: "[proper url]",

contentType: "text/plain; charset=utf-8",

dataType: ($.browser.msie) ? "text" : "xml",

username: '---',

password: '-------',

success: function(data) {

var xml;

if (typeof data == "string") {

alert("Data is string:" + data);

xml = new ActiveXObject("Microsoft.XMLDOM");

xml.async = false;

xml.loadXML(data);

} else {

xml = data;

alert("Data is not string:" + $(xml).text());

}

// Returned data available in object "xml"

//alert("Status is: " + xml.statusText);

$("#ingest_history").html($(xml).text());

}

});







In firefox it works great.





But in IE, the value that I am trying to set for the Accept header seems to get appended onto the end so it becomes: Accept: */*, text/xml . This causes my ajax call to return the html version as opposed to the xml version which I want.





Does anybody know how to properly set/clear the Accept header in IE 8?





Updated: For some reason the asterisks weren't appearing as I entered them. The Accept Header in IE appears to be: Accept: */*, text/xml .



Source: Tips4all

Comments

  1. Your problem seems to be the one described here: http://www.grauw.nl/blog/entry/470. The issue is that the XMLHttpRequest specification currently states that user agents should not set any Accept headers by default for the request, so that req.setRequestHeader() can just append new Accepts. Unfortunately browsers don't yet adhere to this. The problem writeup lets you test your browser to see if it works properly, and unfortunately IE7, Chrome, Safari, Firefox, and Opera all fail.

    Laurens Grauw also talks about the effects of first trying to null out the Accept header with

    setRequestHeader('Accept', '')


    or

    setRequestHeader('Accept', null)


    These might help here.

    Ugly server-side hacks: If you have control over your server-side app you can hardwire it to always return XML, add support for a custom media type like "application/i-really-want-xml", or add support for a custom HTTP header like "X-Accept".

    ReplyDelete
  2. I also had trouble with this, not just in IE but also in Chrome and Safari using jQuery 1.6.2. This solution appears to work as intended in all browsers I've tried (Chrome, Safari, IE, Firefox).

    $.ajax({
    headers: {
    Accept : "text/plain; charset=utf-8",
    "Content-Type": "text/plain; charset=utf-8"
    }
    data: "data",
    success : function(response) {
    ...
    }
    })


    Try that if this is still giving you trouble.

    ReplyDelete
  3. Using jQuery 1.5+ you can set the accepts headers per dataType so you can do something like this:

    $.ajax({
    dataType: ($.browser.msie) ? "text" : "xml",
    accepts: {
    xml: "text/xml",
    text: "text/xml"
    }
    });

    ReplyDelete
  4. I think the original poster might have been referring to this link: http://blogs.msdn.com/ieinternals/archive/2009/07/01/IE-and-the-Accept-Header.aspx however, this doesn't explain the behavior you see.

    IE does not, by itself, have the behavior you describe, and setting the Accept header via XMLHTTPRequest should work properly. I've tested in IE8 to confirm.

    It's possible there's an issue in your version of jQuery, or perhaps you have some plugin mangling your traffic?

    ReplyDelete
  5. I don't believe that IE(any version) plays nice with the Accept header. See this link: [http://blogs.msdn.com/ieinternals/archive/2009/07/01/IE-and-the-Accept-Header.aspx]

    A possible solution might be to check the User Agent to see if it's IE. If it is, then check for the presence of text/xml.

    Good Luck!

    Edit:

    Opps on the link. My hunch was IE is always adding the / and setting the accept header just adds the desired mime type after the /.

    ReplyDelete

Post a Comment

Popular posts from this blog

[韓日関係] 首相含む大幅な内閣改造の可能性…早ければ来月10日ごろ=韓国

div not scrolling properly with slimScroll plugin

I am using the slimScroll plugin for jQuery by Piotr Rochala Which is a great plugin for nice scrollbars on most browsers but I am stuck because I am using it for a chat box and whenever the user appends new text to the boxit does scroll using the .scrollTop() method however the plugin's scrollbar doesnt scroll with it and when the user wants to look though the chat history it will start scrolling from near the top. I have made a quick demo of my situation http://jsfiddle.net/DY9CT/2/ Does anyone know how to solve this problem?

Why does this javascript based printing cause Safari to refresh the page?

The page I am working on has a javascript function executed to print parts of the page. For some reason, printing in Safari, causes the window to somehow update. I say somehow, because it does not really refresh as in reload the page, but rather it starts the "rendering" of the page from start, i.e. scroll to top, flash animations start from 0, and so forth. The effect is reproduced by this fiddle: http://jsfiddle.net/fYmnB/ Clicking the print button and finishing or cancelling a print in Safari causes the screen to "go white" for a sec, which in my real website manifests itself as something "like" a reload. While running print button with, let's say, Firefox, just opens and closes the print dialogue without affecting the fiddle page in any way. Is there something with my way of calling the browsers print method that causes this, or how can it be explained - and preferably, avoided? P.S.: On my real site the same occurs with Chrome. In the ex