Opened 12 years ago

Closed 12 years ago

#4365 closed defect (fixed)

Forced contentType for rawXhrPost appropriate?

Reported by: guest Owned by: anonymous
Priority: high Milestone:
Component: General Version: 0.9
Keywords: Cc: tuomas.kiviaho@…
Blocked By: Blocking:

Description

558 FIXME: is this appropriate for all content types?

559 ioArgs.xhr.setRequestHeader("Content-Type", (args.contentType
_defaultContentType));

I don't think forcing content type in any direction is appropriate in raw xhr cases. Java Servlets for instance give special treatment to content when they encounter x-www-form-urlencoded which happened to be the default content type thus messing up the postData.

Workaround is of course declaration of contentType, but in my case there is no point in telling that to the server.

I'd change the implementation so that default content type is passed along in the same way as "method" is and for raw xhr cases there just wouldn't be any content type by default to pass on.

Change History (1)

comment:1 Changed 12 years ago by alex

Resolution: fixed
Status: newclosed

(In [11174]) complete replacement for the tokenization strategy of the query engine. Moved from ad-hoc substring searching to an AST generation/consumption system. The query engine should be significantly more robust in the face of whitespace and funky formatting than before. Code size change should be minimal despite the large-scale change. Expanded tests and a first stab at inline docs for dojo.query. All unit tests pass on FF2, Safari3, and IE 6 and 7. Fixes #4365. Fixes #4640. Fixes #2423.

Note: See TracTickets for help on using tickets.