Hi Tom, TomH <[EMAIL PROTECTED]> wrote: > ...hopefully all the talking at myself here helps someone > else in the future :P
Or the present! Thanks for sharing your internal roof-brain chatter. I can assure you that it's not simply leaking out into the into the ehter unheard, or unappreciated! > ACTUALLY, it seems to be a mod_python bug, where it looks for an > explicit "application/x-www-form-urlencoded" string in the contentType > header instead of matching it with a regex. following that with any > charset afterwards caused the 501. so i guess a mod_python upgrade > will solve it. Seems that the explicit addition of this defqalt UTF-8 charset to the Content-type header is not just affecting mod_python -- See the message posted just after yours: Re: "Should Ajax.Base specify "encoding:'UTF-8' for 'application/x-www-form-urlencoded'" from "kedoin" [EMAIL PROTECTED] for other unintended consequences triggered in another Apache module, mod_security. I'll take this opportunity to, with no testing, predict that this change in that header will cause issues with File-upload forms on IE, too :-) I wonder why the explicit default was added? Seems to me the path of least surprise would be to leave the encoding out of the Content-type header entirely, unless the user chooses to set it. I'd think that prototype can't "know" (it can only assume) in what encoding my data might be until I tell it, and these character-set/encoding mismatch bugs are often highy visible and difficult to track down. -dave > On Apr 4, 10:42 am, "TomH" <[EMAIL PROTECTED]> wrote: >> Ok, I figured it out. The RC2 sets a default encoding on the request >> of UTF-8, where before the encoding wasn't being set at all. Setting >> encoding = null allowed the postBody to be sent as the key:value >> pair. I am guessing that the lack of an encoding type allows only >> ASCII characters, which is all the particular framework I am using >> allows at the moment. >> >> On Apr 3, 5:42 pm, "TomH" <[EMAIL PROTECTED]> wrote: >> >>> Hello, I've just spent a couple of hours playing with the new >>> release candidate of prototype, and I've noticed some odd behavior >>> when using Ajax.Request to post form data. I have a couple of >>> example scripts here: >> >>> http://www.straightnochaser.org/test/test.html-using RC2 >> >>> http://www.straightnochaser.org/test/test.html-using 1.5.0 >> >>> I know the onComplete doesn't totally work in the second example, >>> but that's not the issue. Open those URLs in firefox with firebug >>> installed, and take a look at the 'post' tab. You should see that is >>> sent as a query string in the first example, but as a key:value pair >>> in the second. I am entering the postBody into the options the same >>> way in both examples, and I took a look at the code of prototype >>> itself in both script versions, but I can't see any code that acts >>> on it differently in each. Why does it post differently? Did I not >>> set a new variable correctly? >> >>> The real reason I ask is that I am using prototype with a >>> custom-built python framework (not built by me) and most of the >>> backend was written to look for post varibles using the original >>> key:value pairs, and it now fails with the new method (error 501). >>> It could be re-written, but the time and cost would be less than >>> ideal, so I would like to make sure this is behavior-as-designed by >>> prototype, and not a bug or something. Though any info on how to >>> fix this on the front-end would be appeciated as well. >> >>> Thanks, >>> -Tom > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" 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/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
