When i compose a POST request on my web service using Fiddler Web Debugger (v4.5.1.2), the expected output does always have a prefix and postfix.
In this case: 23b & 0.
Top screen: (geojson) input, bottom screen: output.
Anyone an idea why this is and how to get rid of it?
When i generate output in Eclipse, the prefix/postfix are not shown.
Cheers!
Turns out that the output is encoded (as stated in the infobar :)). Transforming the output to a regular response gets rid of the prefix and postfix!
Not really a solution, more like a clarification.
Top: Click yellow bar to decode, Bottem: result
Related
I have a Norwegian URL path which looks like this /om-os/bæredygtighed/socialt-ansvar
In my breadcrumb menu, I expect to see something like this:
Om os > Bæredygtighed > Socialt-ansvar
However, the æ is appearing as %c3%a6. So my breadcrumb looks like this:
Om os > B%c3%a6redygtighed > Socialt-ansvar
I have <meta charset="utf-8"> in the head, so I'm unsure why these characters are still appearing?
I don't know how you are building the URLs, but, except for the domains, that have a different encoding, all non-ASCII parts of a URL must be URL-encoded, AKA percent-encoded. The browser does it for you if you don't do it yourself. OTOH, the browser will in most cases show you the unencoded version of your characters. You might not be aware that what is sent over the wire is URL-encoded.
E.g., your path is sent over the wire as /om-os/b%c3%a6redygtighed/socialt-ansvar, even if you see /om-os/bæredygtighed/socialt-ansvar in the address bar. Check it with the developer tools. If you use Firefox, you will have to look at the Headers tab of the HTTP call's details in the Network tab. Chrome, instead, will also show you the HTTP call's summary row URL-encoded. That %c3%a6 in the path is the hex value of the two bytes, C3 and A6, that make up the UTF-8 encoding of the character æ.
You can even set your window.location.pathname programmatically to /om-os/bæredygtighed/socialt-ansvar, but when you read window.location.pathname afterwards, you will get it URL-encoded:
window.location.pathname = '/om-os/bæredygtighed/socialt-ansvar'
[...]
console.log(window.location.pathname)
/om-os/b%C3%A6redygtighed/socialt-ansvar
I don't know how your path flows into your breadcrumbs, but you clearly can reverse the URL-encoding before using your strings.
In JavaScript you normally do that with decodeURIComponent():
console.log(decodeURIComponent('b%c3%a6redygtighed'))
bæredygtighed
console.log(decodeURIComponent('/om-os/b%c3%a6redygtighed/socialt-ansvar'))
/om-os/bæredygtighed/socialt-ansvar
In PHP you normally do that with urldecode:
$decoded = urldecode('b%c3%a6redygtighed'); // will contain 'bæredygtighed'
But it would be better if you could make your data flow in a way that avoids the encoding and decoding steps before reaching your breadcrumbs.
If you have not yet figured out the fix -
just to add on top of whatever walter-tross has already mentioned in above answer -
For the given input - (/om-os/bæredygtighed/socialt-ansvar)
the encodeURI js-method output is as follows -
/om-os/b%C3%A6redygtighed/socialt-ansvar
and the the encodeURIComponent js-method output is as follows -
%2Fom-os%2Fb%C3%A6redygtighed%2Fsocialt-ansvar.
Given the above, it appears that you are fetching the bread-crumb input from the URL. And the behaviour is equivalent to encodeURI method, thus enabling you to split on the '/' character.
The fix, as already noted, would be to perform url-decode using decodeURI or decodeURIComponent on the individual components prior to using it as content.
I have a ASP.NET Web API website, sometimes I just want to see the data returned by HTTP GET. While I know how to get XML or JSON through programming, I don't know where to change the browser's settings (IE, Firefox, and Chrome) to request XML or JSON?
ASP.NET Web API returns JSON or XML based on Accept header.
Different browsers have different default Accept headers. As for me:
Firefox:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,image/jpeg,image/gif;q=0.2,*/*;q=0.1
As text/xml is the most preferable, WebAPI returns XML for Firefox.
IE:
application/x-ms-application, image/jpeg, application/xaml+xml, image/gif, image/pjpeg, application/x-ms-xbap, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */*
Chrome:
*/*
Since XML and JSON are equally acceptable, WebAPI chooses JSON.
How to change these settings
IE generates Accept header value based on registry keys:
HKLM\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Accepted Documents
Firefox stores it in a variable Network.http.accept.default.
You can change it in about:config tab.
I haven't found an information about Chrome. Probably, you can use ModHeader extension to do this.
I am building a WebAPI using Visual Studio 2015.
I'm using Firefox to test it.
I ran the basic project and attempted to call the following WebAPI request to get an object back (serialized as JSON).
When I made the call via Firefox I got an error because Firefox requests XML and WebAPI attempts to default the object to JSON but has no concept for auto-generating the XML.
Resolution
To Fix this you have to go to the Navigation bar of firefox and type :
about:config<ENTER>
You will see a warning screen. Click the button to continue.
You will then see a list of configurable items.
We want the network.http.accept.default.
It's easiest to find if you type the word accept in the top search bar.
Once you find that item. Double-click it and you will be able to edit it.
We just want to add a value that will tell it request JSON as the default.
This header will tell the server that JSON is okay. Since the WebAPI test does not set a specific type to return it allows the browser to control it.
When you double-click the item a dialog box with a edit box will popup.
You want to simply add the following string to the beginning of the existing string.
application/json,
Make sure you give it a trailing comma to separate it from the other existing values. Click the OK button.
As soon as you make that change (clicking OK to finalize it) you can go back to your original tab and make the call to the API method again and it will return JSON as you expect.
Currently I'm working on a small webservice which outputs JSON to the client. For testing purposes I let the JSON output on my browser (Firefox 20). Within the JSON I use tags for declaring text in different languages but it seems that this causes some trouble as my browser filters the start tag.
I guess the browsers (I also tried it on Chrome and Opera) think that the tags are HTML and try to handle it. So I put the JSON code in CODE-Tags and PRE-Tags as well but the result is always the same.
In other words, what I get:
"description":"Bild 1<\/de>Image 1<\/en>\u5199\u771f\u7b2c\u4e00<\/jp>"
What I want:
"description":"<de>Bild 1<\/de><en>Image 1<\/en><jp>\u5199\u771f\u7b2c\u4e00<\/jp>"
Important: The output is what it have to be (says my debugger), it's just how the browser shows it. Is there a possibility to let the browsers ignore the tags or do I have to use "& lt;" and "& gt;"? Thank you!
Escaping XML might seem like the immediate solution, but it is not. It will break your original webservice.
Please recheck if you are sending the below header in the response:
Content-Type: application/json
The above header would make the browsers interpret the response as a JSON (and not HTML)
Yes, try using escape characters XML Escape characters
I'm using Chrome (and IE's) network tools in the debugger to view
what form data I'm sending by ajax calls.
This is the parsed data:
This is the source data:
The lines marked in yellow are what my question is about.
The first picture shows the correct string that I'm sending: description +'---'.
The second picture shows: description%2B'+---', where %2B is code for a plus sign.
I'm wondering, how can there be 2 plus signs in the second picture (the actual plus and the %2B)? Furthermore, what is this second plus doing inside the quotes?
That's not the data that I'm sending. On the server side it receives correctly, but I'm just wondering, is it a bug in IE and chrome Debugger or am I missing something?
Thanks
You are missing something, but it's very subtle: in application/x-www-form-urlencoded encoding, the space character is changed to a +. So the second plus is not a plus, but rather an encoded space.
For more information, see the answer to this question.
When I view the source of the page in my browser (FireFox) (View->Page Source), copy it and paste it into my HTML editor, I view almost the same page (In this example it is www.google.com) as it appears in my browser. But when I get the HTML source through this code (through Googles App Engines)
from google.appengine.api import urlfetch
url = "http://www.google.com/"
result = urlfetch.fetch(url)
if result.status_code == 200:
print result.content
copy it and paste it into my HTML editor, the page then looks quite different. Why is it so? Is there something wrong with the code?
++++++++++++++++++++++++++++++
Follow-up:
By this moment (Sunday, December 13th, 2009, 1:01 PM, GMT, to be precise) I have received two comments-questions (from Aaron and Christian P.) and one answer from Alex Martelli.
Both Aaron and Christian P. are asking about what actually is different between the Fire-Fox-obtained source and Google-App-Engine-obtained source when they are both displayed through the same HTML editor.
Here I have uploaded too screen shots:
One shows the Fire-Fox-obtained source
And the other one shows Google-App-Engine-obtained source
when they are both displayed through “MS Front Page” editor.
One difference, which is quite obvious, is different encoding: In Fire-Fox code everything is displayed in English, while in the Google-App-Engine code I get a lot of various symbols, instead.
Another difference is some additional lines at the top of the page in the Google App Engine code. I think, this is what Alex Martelli was talking about in his answer (“…the fetch-and-print approach is going to have metadata around it as well…”).
One more minor difference is that the box for the Google image is split into several boxes in one code, while it remains whole in the other one.
Alex Martelli suggested that I use this code (if I understood him correctly):
from google.appengine.api import urlfetch
url = "http://www.google.com/"
result = urlfetch.fetch(url)
if result.status_code == 200:
print "content-type: text/plain"
print
I’ve tried it, but in this case nothing is displayed at all.
Thank you all for your responses and, please, continue responding – I really want to see this issue finally resolved.
++++++++++++++++++++++++++++++
Follow-up:
Okay, the issue has been resolved.
I failed to pay my full attention to Alex Martelli's instructions and, therefore, came up with a wrong code. Here is he right one:
from google.appengine.api import urlfetch
url = "http://www.google.com/"
result = urlfetch.fetch(url)
if result.status_code == 200:
print "content-type: text/plain"
print
print result.content
This code displays exactly what is needed - no additional lines at the top of the page.
Well, I still get the strange symbols, but I discovered that it's probably Google's problem. The thing is I am currently in Taiwan, and Google seems to be aware of that and automatically switches from www.google.com (which is in English) to www.google.com.tw (which is in Chinese), but this one, I guess, is already another topic.
Thanks to everyone who has responded here.
You have not explicitly emitted a "content type" header, and an end-of-headers empty line, so the first few lines are probably going to be lost; try adding before the final print something like
print "content-type: text/plain"
print
Beyond this, what you're getting in either case is essentially a big <script> with a little extra HTML around it -- that's all that Firefox is going to give you in the "view source" page, while the fetch-and-print approach is going to have metadata around it as well, e.g., the "doctype" (depending on what HTML editor you're targeting, this may or may not be an issue).