It seems like it'd be easy to special-case POST requests to make sure
that an empty string was sent. Could you file a bug on the issue?
Thanks!

--John



On Thu, Apr 16, 2009 at 9:38 AM, Rebecca Murphey <[email protected]> wrote:
>
> The issue didn't occur in IE; I haven't tested in C or S.
>
> As far as POSTing without data, I agree that this is illogical, but it
> was what the client (as in the person who pays me, not as in the
> browser) required to interface with their server-side code. I have
> tried repeatedly to get them to use GET where appropriate, to no
> avail.
>
> I made the change you suggested, setting the data to an empty string
> if it was null or undefined, and of course it worked fine.
>
> My more general question was, considering that different browsers
> handle the situation differently, is this something jQuery should
> resolve? Or is the onus on the developer to know that a data-less POST
> may cause issues for some users?
>
> On Apr 15, 10:28 am, DBJDBJ <[email protected]> wrote:
>> for data sent jQ (-vsdoc.js version) says this :
>>
>> 5074#                   // Set the correct header, if data is being sent
>> 5075#                   if ( s.data )
>> 5076#                           xhr.setRequestHeader("Content-Type", 
>> s.contentType);
>>
>> before actually sending.
>> jQ does not set "Content-Length" specificaly. This is the job of
>> XmlHttpRequest.
>>
>> It is not clear from your message if you have tested this using IE or
>> C ?
>>
>> Although, in my book this is users/callers error: one should not
>> "POST" with no data, me thinks ;o)
>>
>> But if you think there is some logic in that you can simply do :
>>
>> $.ajax({
>>   'url' : 'foo.php',
>>   'data' : (! myData ? "" : myData) ,
>>   'type' : 'POST',
>>   'dataType' : 'json',
>>   'success' : function(j) {
>>     // whatever
>>   }
>>
>> });
>>
>> Which might work since jQ does not check if user is sending empty
>> string as data.
>>
>> 4958#           // convert data if not already a string
>> 4959#           if ( s.data && s.processData && typeof s.data !== "string" )
>> 4960#                   s.data = jQuery.param(s.data);
>>
>> (same ...-vsdoc.js version )
>>
>> -- DBJ
>>
>> On Apr 14, 4:21 pm, Rebecca Murphey <[email protected]> wrote:
>>
>> > correction, the title of this should say
>>
>> >   $.ajax() WITH null data property in config object results in missing
>> > Content-Length header in FF3
>>
>> > On Apr 14, 10:34 am, Rebecca <[email protected]> wrote:
>>
>> > > Just experienced this in Firefox 3, not sure whether it is desired
>> > > behavior, but discussed it with a fellow dev and we think it is not.
>>
>> > > I had an ajax request as follows:
>>
>> > > var myData = null;
>>
>> > > $.ajax({
>> > >   'url' : 'foo.php',
>> > >   'data' : myData,
>> > >   'type' : 'POST',
>> > >   'dataType' : 'json',
>> > >   'success' : function(j) {
>> > >     // whatever
>> > >   }
>>
>> > > });
>>
>> > > Client was reporting a 411 HTTP response code on the request -- their
>> > > proxy was expecting a Content-Length header on the request, and wasn't
>> > > getting one. This also occurred if myData was undefined. It did *not*
>> > > occur when myData was {}.
>>
>> > > We hadn't detected this error internally because our requests weren't
>> > > proxy'd. It seems Content-Length "should" always be there
>>
>> > >http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.13
>>
>> > > and should be 0 if myData is null or undefined.
>>
>> > > I'm not sure whether this is just a Firefox issue, or something that
>> > > jQuery should address in the spirit of abstracting away browser
>> > > differences?
> >
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"jQuery Development" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/jquery-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to