broberts wrote: > Szymon, > > Good thought. Since our Web server is an intranet Web server, I've > got to find a machine on our local network where I can run a Linux > distro so that I can utilize the WGET, and GUNZIP commands. I will > try it out today and let you know what I find. >
Ok, I got the hex codes of malformed response, saved those to file and tried to recognize it, but no success. Its not gzip, bzip2 neither compress. So, seems it's not compressed (witch I thought it's not when I noticed plain "56" digits in hex view of malformed response...) Also tried to get it through iconv to convert it from any of supported encodings in a loop. No success It bails out on position 0, 3, 4 or 5. So it is neither of character sets supported by iconv. #file claims it to be just "data"... Unless I made a mistake somewhere while entering hex data, I am out of ideas. Wish you luck, Szymon > On Apr 15, 9:48 am, SWilk <[EMAIL PROTECTED]> wrote: >> Hi, >> >> Just a thought... Have you checked if your Apache configuration >> enforce compression (eg. gzip) on the data with 'application/json' >> content type (or, rather, to any unknown content-type) while not >> adding proper transfer-encoding header? >> In such situation browser would not uncompress the response. >> >> try running >> # wget -O -http://your.address/here| gunzip - >> >> It is rather unprobable situation, but it's always worth to test it. >> >> -- >> Regards, >> Szymon Wilkołazki >> >> broberts wrote: >>> Michael, >>> Do you mean "Does the AS/400 use an unusual character set?" Well, >>> when it comes to encoding, I begin to get lost in the discussion of >>> charsets, ASCII, and EBCDIC (IBM's standard). I would assume that the >>> data comes from the AS/400 in EBCDIC, but has to be transcoded as some >>> point. I'm not sure when/where the transcoding takes places. >>> Since you thought Firebug might be suspect in terms of how it presents >>> the response, I used Fiddler and WGET. When I using other tools (e.g. >>> Fiddler) to inspect the HTTP activity, it also shows the response the >>> garbled. Here's the response show by Fiddler: >>> �% ���������� [EMAIL PROTECTED] ������ z k% ������� z k% ������ >>> z k >>> % ���� z@ % �%� >>> Here's the complete response from the Web server when the Content-Type >>> is 'application/json': >>> --- >>> HTTP/1.1 200 OK >>> Date: Tue, 15 Apr 2008 14:06:07 GMT >>> Server: Apache >>> Content-Type: application/json >>> Content-Length: 86 >>> �% ���������� [EMAIL PROTECTED] ������ z k% ������� z k% ������ >>> z k >>> % ���� z@ % �%� >>> --- >>> When changing the Content-Type to 'text/javascript', the response is >>> as expected. However, the correct standard for JSON-formatted HTTP >>> responses is to set the Content-Type to 'application/json'. Here's >>> the response when the Content-Type is set to 'text'javascript': >>> --- >>> HTTP/1.1 200 OK >>> Date: Tue, 15 Apr 2008 14:20:09 GMT >>> Server: Apache >>> Transfer-Encoding: chunked >>> Content-Type: text/javascript; charset=ISO-8859-1 >>> 56 >>> { >>> "srvpgmresp": { >>> "status": "ok", >>> "purpose": "user", >>> "rtncod": "1", >>> "body": "Empty" >>> } >>> } >>> 0 >>> --- >>> I really suspect the Apache Web server or some other software with its >>> hand in the transcoding process. Any help is appreciated. >>> On Apr 15, 3:34 am, Michael Stillwell <[EMAIL PROTECTED]> >>> wrote: >>>> I'd also check that the content you're getting from the server really >>>> is different (via e.g. wget or netcat or telnetting to the port) >>>> instead of trusting Firebug--I've never known Apache to change the >>>> encoding of anything that flows through it (adding headers is a >>>> different story), though Apache does have lots of modules that do lots >>>> of things and maybe transcoding is more necessary on AS/400... (Does >>>> it use an "unusual" character set?) --M. >>>> On Apr 14, 11:00 pm, broberts <[EMAIL PROTECTED]> wrote: >>>>> I cannot find any reference to 'defaultchartype' in my config file. >>>>> However, the Apache config starts out with a number of AddType >>>>> declarations that look promising... >>>>> AddType text/plain .java >>>>> AddType text/xml .xml >>>>> AddType text/x-hdml .hdml >>>>> AddType text/vnd.wap.wml .wml >>>>> AddType image/gif .gif >>>>> AddType text/html .htm >>>>> AddType text/html .html >>>>> AddType text/x-component .htc >>>>> Maybe I need to add... >>>>> AddType application/json .js >>>>> Let me know what you think. I'm going to research it a little more >>>>> before I make changes the Web server's configuration. >>>>> On Apr 14, 4:53 pm, "Brian Williams" <[EMAIL PROTECTED]> wrote: >>>>>> Apache on the ass/400 never really thunk of it... >>>>>> which version? >>>>>> one thing you might want to check is the defaultchartype in the >>>>>> httpd.conf >>>>>> file or the server specific directives, thats the first thing i check >>>>>> when i >>>>>> have garbled output like that >>>>>> On Mon, Apr 14, 2008 at 5:45 PM, broberts <[EMAIL PROTECTED]> wrote: >>>>>>> Yes, the code on your server works for me. Though I didn't seem to me >>>>>>> that it would make any difference, I had a quick thought that it might >>>>>>> be that I was using the GET method rather than the POST method. >>>>>>> However, changing the method had no effect. >>>>>>> I'm using Firebug to inspect the DOM, GET/POST request, and the >>>>>>> response. When I get the response back, it's garbled. As long as I >>>>>>> specify the content-type as 'text/javascript' (and set the evalJSON >>>>>>> parm to 'force'), the responseJSON property is populated correctly. >>>>>>> However, when I set the content-type to 'application/json', the >>>>>>> response (i.e. responseText property) comes back garbled. It contains >>>>>>> non-printable characters. It's quite strange. Here's a copy & paste >>>>>>> of the response: >>>>>>> �% ���������� [EMAIL PROTECTED] ������ z k% ������� z k% >>>>>>> ������ z k >>>>>>> % ���� z@ % �% >>>>>>> We're running Apache on an IBM AS/400 machine, so our instance of >>>>>>> Apache might not like the 'application/json' content type. Have you >>>>>>> heard of this before? Can the Apache config file impact the content >>>>>>> types the Apache Web Server is willing to serve up? >>>>>>> Thanks! >>>>>>> On Apr 14, 4:12 pm, Michael Stillwell <[EMAIL PROTECTED]> >>>>>>> wrote: >>>>>>>> That works fine for me; see: >>>>>>>> http://beebo.org/scratch/test.html >>>>>>>> which Ajax.Requests: >>>>>>>> http://beebo.org/scratch/test.php >>>>>>>> --M. >>>>>>>> On Apr 14, 9:53 pm, broberts <[EMAIL PROTECTED]> wrote: >>>>>>>>> { >>>>>>>>> "response": { >>>>>>>>> "status": "ok", >>>>>>>>> "purpose": "user", >>>>>>>>> "rtncod": "1234", >>>>>>>>> "body": "It worked" >>>>>>>>> } >>>>>>>>> } >>>>>>>>> On Apr 14, 3:13 pm, Michael Stillwell <[EMAIL PROTECTED]> >>>>>>>>> wrote: >>>>>>>>>> On Apr 14, 6:35 pm, broberts <[EMAIL PROTECTED]> wrote: >>>>>>>>>>> In Firefox 2.x and IE6 (the browsers I've tested in thus far), the >>>>>>>>>>> responseJSON property of the Ajax.Response object is null when I >>>>>>> set >>>>>>>>>>> the response content-type to "application/json". >>>>>>>>>> That should work. What's the exact JSON that's being returned from >>>>>>>>>> the server? If it's a string it needs to be quoted: >>>>>>>>>> "Hello, World!" >>>>>>>>>> --M. > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
