Re: XHR setting headers
* Julian Reschke wrote: Peter Michaux wrote: I think all XMLHttpRequest headers should be specified as blank when the object is created. Then the JavaScript can add any headers it needs to add. If, when the call to send() occurs, some essential header(s) is missing the XHMLHttpRequest object should add these automatically but only according to specified behavior. The whole append semantics is problematic as long as the user can't find out what the current value is. IMHO we need either removeRequestHeader(), getRequestHeader(), or both. I once suggested making setRequestHeader with null remove the stored value, I am not sure why this has no effect instead. I do note that it is unlikely that the set of headers the implementation will ultimately pass on to the next hop will ever be fully deterministic based only on published specifications. Similarily, I don't think mixing control over your own headers, and those added or modified by the implementation in the same API is a good idea: it cannot know whether removeRH is meant to simply clear a previous setRequestHeader value, or meant to somehow surpress an implementation default; the implementation also may not be able to accurately predict the value of certain headers at the point where the script wants to know them (or what it does report becomes in- valid because other headers are set by the script). One case here is if the client learns about certain features of the server only the moment before the request is dispatched (like whether it supports HTTP/1.1 or pipelined requests or has some particular bug that needs to be worked around). So I would suggest a separate API is in order here, if one is needed at all. -- Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Re: XHR setting headers
Anne van Kesteren wrote: On Mon, 12 May 2008 17:24:16 +0200, Julian Reschke [EMAIL PROTECTED] wrote: Well, we just heard from people complaining about XHR implementations pre-filling request headers, and thus causing clients to create broken content-type headers (because of the append functionality). Actually, that was specifically about Accept and it seems to be simply an Opera bug per the specification. So does the specification say which headers may be prefilled by the implementation, and when? BR, Julian
Re: XHR setting headers
On Thu, 17 Apr 2008 01:49:44 +0200, Peter Michaux [EMAIL PROTECTED] wrote: The XMLHttpRequest spec says The setRequestHeader() method appends a value if the HTTP header given as argument is already part of the list of request headers. This is fine but what is a problem is whether or not a new XHMHttpRequest object has any default headers. I was trying to use the Accept header a few days ago and I wanted to have only Accept: application/json but Opera has a default header Accept: text/html, text/xhtml, etc so my application/json was appended to the front of that list which makes my Accept header useless as part of the client-server communication. The server thinks that the client knows what to do with text/html. My JavaScript certainly does NOT know what to do with text/html. My JavaScript only knows how to handle application/json. That seems like a problem with Opera. Have you filed a bug report? https://bugs.opera.com/wizard/ I think all XMLHttpRequest headers should be specified as blank when the object is created. Then the JavaScript can add any headers it needs to add. If, when the call to send() occurs, some essential header(s) is missing the XHMLHttpRequest object should add these automatically but only according to specified behavior. In general this should already be the case, but for some headers it would pose security or privacy issues if they were allowed to be set by the author. In any case, for Accept this was never an issue with the specification. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: XHR setting headers
On Thu, 17 Apr 2008 15:31:37 +0200, Julian Reschke [EMAIL PROTECTED] wrote: The whole append semantics is problematic as long as the user can't find out what the current value is. IMHO we need either removeRequestHeader(), getRequestHeader(), or both. Yes, you have already stated this before. So far, there does not seem to be too much demand for these features and they would either way be out of scope for XMLHttpRequest Level 1 at this point. Kind regards, -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: XHR setting headers
Anne van Kesteren wrote: On Thu, 17 Apr 2008 15:31:37 +0200, Julian Reschke [EMAIL PROTECTED] wrote: The whole append semantics is problematic as long as the user can't find out what the current value is. IMHO we need either removeRequestHeader(), getRequestHeader(), or both. Yes, you have already stated this before. So far, there does not seem to be too much demand for these features and they would either way be out of scope for XMLHttpRequest Level 1 at this point. Well, we just heard from people complaining about XHR implementations pre-filling request headers, and thus causing clients to create broken content-type headers (because of the append functionality). BR, Julian
Re: XHR setting headers
Sunava Dutta wrote: IMHO we need either removeRequestHeader(), getRequestHeader(), or both. GetRequestHeader could pose a security risk, because you could then GetRequestHeader (Cookie) and steal HTTPOnly cookies. Sure. It would need to be done correctly. That doesn't change the fact that in XHR1, control over the request headers is totally insufficient. BR, Julian
Re: XHR setting headers
Peter Michaux wrote: The XMLHttpRequest spec says The setRequestHeader() method appends a value if the HTTP header given as argument is already part of the list of request headers. This is fine but what is a problem is whether or not a new XHMHttpRequest object has any default headers. I was trying to use the Accept header a few days ago and I wanted to have only Accept: application/json but Opera has a default header Accept: text/html, text/xhtml, etc so my application/json was appended to the front of that list which makes my Accept header useless as part of the client-server communication. The server thinks that the client knows what to do with text/html. My JavaScript certainly does NOT know what to do with text/html. My JavaScript only knows how to handle application/json. I think all XMLHttpRequest headers should be specified as blank when the object is created. Then the JavaScript can add any headers it needs to add. If, when the call to send() occurs, some essential header(s) is missing the XHMLHttpRequest object should add these automatically but only according to specified behavior. The whole append semantics is problematic as long as the user can't find out what the current value is. IMHO we need either removeRequestHeader(), getRequestHeader(), or both. BR, Julian PS: I may sound like a broken record WRT this, but anyway.
