There is a confusion in setting multiple values to the headers according to RFC2616, the response header values should be comma separated, but when i look at certain headers they are semicolon separated for example in the w3 site if you see the response header "content-type" its a semi-colon separated value.
w3 site .
If semicolon is accepted then ,
the second question is when we cache-control with semicolon separated values the cache-control does not behave correctly in chrome but works fine in fire fox.
For Example ,consider the following image cachecontrol the values are semicolon separated and the behavior that is expected and working in firefox is it should not cache the page but chrome defies this and caches the page. Any help on clarification is highly appreciated, Thanks!
Related
I work with a legacy ASP.NET web application that has URLs that use query string values to pass information between pages. I ran into an issue with a couple of URLs that contain spaces, numbers, and dashes that I'm trying to understand.
Here's an example of the URL:
http://myserver.com/SelectReport.aspx?Name=My Report&ReportFile=my_financial_report&ReportTitle=My Financial Planning Across A 1-Year Or 2-Year Outlook
The problematic part of the URL is the ReportTitle query string value.
When I click the link in Internet Explorer 11 or Microsoft Edge, I get a Cant' reach this page. It took too long to connect to this website. Error Code: INET_E_CONNECTION_TIMEOUT error. It should be noted that the link works fine if I turn ON compatibility view settings in Internet Explorer 11.
When I click the link in Google Chrome, I get a `This site can't be reached. The connection was reset. ERR_CONNECTION_RESET" error.
If I delete the 2 in 2-Year, the link works. However, if I delete the 1 in 1-Year and leave 2-Year alone, the link does not work. I'd like to know why removing the 2 in 2-Year allows the link to work, but removing the 1 in 1-Year does not. This is true whether I replace spaces with %20 or not. Does anyone know the answer?
I know that I can replace the spaces in the ReportTitle query string value with plus signs (+) and it will work. This is likely the route I will take to fix the issue, but I was hoping to understand the issue better.
Thanks!
This is the continuation of my comments in the original post. I am writing this answer to share the demo example. It may not be a full answer.
There is absolutely no difference when you have spaces, or spaces are replaced by %20 or spaces are replaced by +. Also, I mentioned earlier your URL has valid characters including -.
See the three links below. I suspect it is your application that is dealing with URL encoding, decoding and having issues. It is not a general problem.
With Spaces
<br>
With %20
<br>
With +
I'm working on SEO for a Rails App.
The website is fully localized, and I'm following this google article to add hreflang alternate links to the pages.
The HTML links in the <head> are ok.
I'm having some troubles with the response headers.
I understand that I'm supposed to provide values for each alternative version of the page, but I'm not sure about how to set multiple values.
I tried to pass them as a comma separated list. Browsers seem to receive it correctly, but since individual values contain semi-colons it looks wrong.
Is there any reference on it?
Even an example webpage that is known to implement it correctly would help.
I have no experience with this, but according to the examples in the same RFC they get separated by comma:
Link: </TheBook/chapter2>;
rel="previous"; title*=UTF-8'de'letztes%20Kapitel,
</TheBook/chapter4>;
rel="next"; title*=UTF-8'de'n%c3%a4chstes%20Kapitel
It’s indirectly confirmed by 5.3 (emphasis mine):
Note that extension relation types are REQUIRED to be absolute URIs in Link headers, and MUST be quoted if they contain a semicolon (";") or comma (",") (as these characters are used as delimiters in the header itself).
Most of websites when shown with the http://www.rexswain.com/httpview.html viewer display some extra characters before the DOCTYPE and also after the ending HTML tag.
Is this really sent by the server or it's a bug of the rexswain viewer ?
EDIT:
For example, the first 2 lines of drupalfrance.com are
7add(CR)(LF)
<!DOCTYPE·html·PUBLIC·"-//W3C//DTD·XHTML+RDFa·1.0//EN"(LF)
and the 4 last lines are
</html>(LF)
(CR)(LF)
0(CR)(LF)
(CR)(LF)
In the HTTP header, notice Transfer Encoding: chunked.
The hexadecimal number (followed by CR,LF) is the number of characters in the following chunk. In your case, 7add = 31453. Then 0,CR,LF indicates the end.
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.