Frank, I am sorry you took time checking this. I guess, this
recommendation "Optimally, the reply should be to the thread started
by the original question posting, and should have 'FIXED', 'RESOLVED'
or an equally obvious tag in the subject line." from
http://www.catb.org/~esr/faqs/smart-questions.html does not work well
with GMail threaded messages. I will not use it anymore.
Anyway, this thing with setting content type did the trick. Amazing.
LiveHTTPHeaders still show the bizzare output, but everything works.
I am off to Barnes&Noble, will take a look at the book. If it mentions
this "bugofeature" I will buy it ;-)
Thanks again for replying!
Michael.
On 3/11/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
> Weird, I can't explain that. I just did this as a test:
>
> <html><head><title></title>
> <script>
> xhr = null;
> function test() {
> if (window.XMLHttpRequest) {
> xhr = new XMLHttpRequest();
> } else {
> xhr = new ActiveXObject("Microsoft.XMLHTTP");
> }
> xhr.onreadystatechange = handler;
> xhr.open("post", "test.htm", true);
> xhr.send("p1=v1&p2=v2&p3=v3");
> }
> function handler() {
> alert("handler()");
> }
> </script>
> </head><body>
> <input type="button" onClick="test();">
> </body></html>
>
> Should be virtually identical to what your doing. At least under IE
> using HTTPWatch, I see the parameters as POST content as expected, not
> appended to any header or anything. For some reason LiveHTTPHeaders
> didn't even seem to want to capture for me (for all the bragging people
> do about FF, I have more trouble getting it to do what I want!). I
> wonder if LiveHTTPHeaders is getting it wrong? Or maybe just displaying
> some odd way that makes it look like it's a child of that header? I
> don't know, just guessing.
>
> Oh, I see your reply about content type just now... did that solve this
> problem? I've never had to set the content type before, and I've sent
> chunks of XML as well as plain strings and even a query string like your
> doing many times in a POST using XHR, both FF and IE, never seen any
> problem like this.
>
> Frank
>
> Michael Jouravlev wrote:
> > Thanks, Frank. I guess I need this book :) Before I get it, allow me
> > one more question.
> >
> > I have a working XHR using GET (target is full URL with query params):
> >
> > ajaxRequest.open("GET", target, true);
> > ajaxRequest.send(null);
> >
> > Now I want to switch to POST (url is base URL, params contain request
> > params):
> >
> > ajaxRequest.open("POST", url, true);
> > ajaxRequest.send(params);
> >
> > It does not work. The parameters are sent, but apparently not as
> > content, but as "Cache-Control" attributes. The working POST request
> > shows like this in LiveHTTPHeaders (another test app):
> >
> > POST /strutsdialog/dialogloginactioncontrol.do HTTP/1.1
> > ...
> > Content-Length: 41
> > name=&password=&DIALOG-EVENT-LOGIN=Log+In
> >
> > The non-working XHR POST request looks like this:
> >
> > POST /jspcontrols-samples/login/loginComponent.jsp HTTP/1.1
> > ...
> > Content-Length: 68
> > Cache-Control: no-cache
> > jspcontrols.ajax.xhtml=true&loginEvent=1&username=user&password=pass
> >
> > Here my parameters are listed as a child for "Cache-Control" element.
> > Application does not see them.
> >
> > What I am doing wrong and how to do it right?
> >
> > Michael
> >
> > On 3/11/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
> >> The Manning AJAX In Action book has an appendix that covers a great many
> >> of these useful techniques. Even if you have zero interest in AJAX, I
> >> haven't seen many books or articles that covers Javascript as well as
> >> this one. I consider myself fairly well-versed in Javascript, and even
> >> I picked up a trick or two and otherwise solidified by understanding.
> >> Very much recommended (yeah, and the coverage of AJAX ain't bad either!)
> >>
> >> Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
