Opened 11 years ago

Closed 11 years ago

Last modified 10 years ago

#8724 closed defect (fixed)

dojo.xhr with method post passes params via URL

Reported by: foobarfighter Owned by: James Burke
Priority: high Milestone: 1.4
Component: IO Version: 1.2.3
Keywords: Cc:
Blocked By: Blocking:

Description

This code will send the params to the URL http://localhost:3000/form_observers/show?foo=bar

dojo.xhr('post', { content: { foo: 'bar' }, url: 'http://localhost:3000/form_observers/show' });

It should send the params to http://localhost:3000/form_observers/show with the form params in the message body although it still does a request via HTTP POST.

I'll try and submit a patch by tomorrow night if somebody else doesn't get to this first.

I went through a lot of different param combinations with dmachi, but this appears to be a bug.

Also, it appears that dojo.xhrPost works correctly.

Regards, foobarfighter (Bob Remeika)

Change History (5)

comment:1 Changed 11 years ago by dante

if you add "true" to the third param it behaves as expected. this is the hasBody param, and i've never figured out why it is there.

dojo.xhrPost() == dojo.xhr("POST", {}, true);

adding hasBody to your url properly posts the content of the object. want to mark invalid.

comment:2 Changed 11 years ago by foobarfighter

Ah, I was passing hasBody as an ioArg in my tests with dmachi which explains why I was still having the problem (there was something lost in translation there). My assumption is that dojo.xhrPost is a convenience method for dojo.xhr('POST' ... ), but is this really necessary? Shouldn't dojo.xhr be smart enough to account for this?

My use case is that I have an abstraction on top of dojo.xhr and I don't know what kind of request method that will be passed in ahead of time. I don't want to have a switch statement or do any meta programming to delegate to the appropriate function or pass additional args based on the request method in my abstraction layer. My hope was that dojo.xhr would handle this sort of thing appropriately without having to do any method delegation.

Thoughts?

comment:3 Changed 11 years ago by James Burke

Milestone: tbd1.4

The hasBody was a poor solution (by me) to get the dojo.rawXhrPost and dojo.rawXhrPut to work with the dojo.xhr scheme. In retrospect, it would have been nice to have a arg.rawBody param instead of args.postData and args.putData to help with that situation.

In addition, it would be nice if dojo.xhr would know which methods expect the query content in the URL or as an HTTP body. However, this would require a survey of known HTTP methods, not just the basic ones but other ones use by say, WebDAV. Maybe we can get away with only GET having it on the URL, everything else uses the HTTP body.

I agree this should be cleaned up.

comment:4 Changed 11 years ago by James Burke

Resolution: fixed
Status: newclosed

(In [17469]) Fixes #9219, #8649, #7833 and #8724: allow publication of IO pipeline topics, add dojo.fieldToObject (thanks to foobarfighter, CLA on file), allow generic args.rawBody for setting HTTP request bodies, and if hasBody is not passed to dojo.xhr, make an intelligent guess as to whether the query should be in the http body or as a query string. \!strict for dojo.io.script code has not side effects warning, but it is ok.

comment:5 Changed 10 years ago by foobarfighter

Oh awesome!! I realize that this is an old post but I just recently checked the ticket. I'm so stoked that some of my code is in core! Thanks jburke :)

Note: See TracTickets for help on using tickets.