I'm trying to understand the difference between querystrings and headers. Where do you use each?
Query strings might be more useful in making URLs human readable I suppose, but other than that, wouldn't it be easier to just embed that in your own custom HTTP header (side question, but how this relate to cookies?)? What's the distinction between the two?
Refer a similar question Adding Custom HTTP Headers
Why would I prefer query string over http-header fields?
It is easy
I don't need any additional API
It is also recommended in
HTTP-RFC to "follow common-forms" when it comes to header
fields.
Related
I just stumbled across this question:
Is it still an acceptable thing to use custom header fields and if yes how should they be named?
As far as i knew custom fields start with an X-.. but according to RFC 6648 these are depricated since 2012 but I also haven't found any proposals for alternatives from them.
So would it make sense to name custom fields just "normal" (without an X-Prefix)? Does it makes sense at all to use custom fields for exchanging additional information?
Just name them normally. See, e.g., Custom HTTP headers : naming conventions
Whether it makes sense to use them depends on the application. They can certainly be used for things done in middleware such as authentication tokens, for example.
If there is something you really want checked by the server before it spins off endpoint-specific data processing code, the headers aren't a terrible place to put the relevant data.
I am using webApi 2 for my application. i have gallery and i need a way to show my images. I've searched a lot and found some articles like these :
http://www.dotnetcurry.com/aspnet/1120/aspnet-webapi-binary-contents-images
https://jamessdixon.wordpress.com/2013/10/01/handling-images-in-webapi/
but they seems they don't have a efficient way.
so I decide to ask this question once again. how can I handle my images in web api 2 ?
what's the best approach?
Without a little more info on your use case, it's hard to know what the best way would be. Typically a formatter would be used. Then your client would make two requests, /api/Images to get all your images, then create the proper views for each image (HTML would be ). A route that accepts an extension is needed and a formatter to return the proper content type and binary data. Your controller could do all the binary streaming, but a formatter allows better flexibility.
As for BSON, I have never used BSON. Our API has so many different clients that JSON is universal for our DTO's. For images, we always use the the response body for the pure binary stream. This way there is no custom parsing that each client has to do. We can rely completely on the HTTP specs by using the proper content-type, content-length, etc. This also allows for a range request so we can stream and do partial downloads with resume. I have no doubt BSON will catch on and we'll probably use it in the future, but for now it doesn't fit our use case.
Recently, we found that some of our SpringMVC based site's pages, that accept query parameters, are susceptible to XSS attacks. For e.g. a url like http://www.our-site.com/page?s='-(console.log(document.cookie))-'&a=1&fx=326tTDE could result in the injected JS to be executed in the context of the rendered page. These pages are all GET-based, no POST requests are supported.
These parameters are written in the markup in numerous places, so doing an HTML encode (in all these places) would be tedious and require more code changes. In some cases, they are also written to cookies.
Ideally, we would want to detect them as early as possible, say inside a Servlet Filter/Spring Interceptor and then for each request parameter, decide if we want to drop it all together, or sanitize it in some way, before it's available to the rest of the application. We would want this decision to be configurable as well, so that the approach to handle a particular request parameter can be modified over time without significant code change.
Now, since these are request parameters that we want to potentially modify, we would probably have to use an approach similar to the one described here, if we go the Filter way. We would potentially want to sanitize HTTP Request Headers similarly too.
So, what would be the most flexible/minimum overhead way to handle this situation? Would ESAPI be able to both detect and sanitize them, in a configurable way? It's not clear from its API as to what is possible. We would definitely not want to hand-roll regexes to do this. Also, would a Filter be the right place to handle this?
Thanks.
I'm thinking about implementing an RPC mechanism over HTTP. The POST method seems to be suitable for the calls. However, since each call comes with the binary payload, there's a decision to be made about how to attach that binary data to the POST request. It seems there are two content types for POSTs of use today: application/x-www-form-urlencoded and multipart/form-data. The former seems to require percent-escaping binary data, while the latter seems to add some overhead with the boundaries/content-disposition fields.
Therefore my question is: how good is it to just use application/octet-stream as a POST content type and just include the binary payload afterwards as is? Will it go through all proxies? Will all HTTP servers be able to handle this? Is it standards-compliant? In other words, should I go for it?
Yes, you can do that; but it would be better to use a more specific type that makes the message self-descriptive.
I was wondering whether search engines respect the HTTP header field Content-Location.
This could be useful, for example, when you want to remove the session ID argument out of the URL:
GET /foo/bar?sid=0123456789 HTTP/1.1
Host: example.com
…
HTTP/1.1 200 OK
Content-Location: http://example.com/foo/bar
…
Clarification:
I don’t want to redirect the request, as removing the session ID would lead to a completely different request and thus probably also a different response. I just want to state that the enclosed response is also available under its “main URL”.
Maybe my example was not a good representation of the intent of my question. So please take a look at What is the purpose of the HTTP header field “Content-Location”?.
I think Google just announced the answer to my question: the canonical link relation for declaring the canonical URL.
Maile Ohye from Google wrote:
MickeyC said...
You should have used the Content-Location header instead, as per:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
"14.14 Content-Location"
#MikeyC: Yes, from a theoretical standpoint that makes sense and we certainly considered it. A few points, however, led us to choose :
Our data showed that the "Content-Location" header is configured improperly on many web sites. Sometimes webmasters provide long, ugly URLs that aren’t even duplicates -- it's probably unintentional. They're likely unaware that their webserver is even sending the Content-Location header.
It would've been extremely time consuming to contact site owners to clean up the Content-Location issues throughout the web. We realized that if we started with a clean slate, we could provide the functionality more quickly. With Microsoft and Yahoo! on-board to support this format, webmasters need to only learn one syntax.
Often webmasters have difficulty configuring their web server headers, but can more easily change their HTML. rel="canonical" seemed like a friendly attribute.
http://googlewebmastercentral.blogspot.com/2009/02/specify-your-canonical.html?showComment=1234714860000#c8376597054104610625
Most decent crawlers do follow Content-Location. So, yes, search engines respect the Content-Location header, although that is no guarantee that the URL having the sid parameter will not be on the results page.
In 2009 Google started looking at URIs qualified as rel=canonical in the response body.
Looks like since 2011, links formatted as per RFC5988 are also parsed from the header field Link:. It is also clearly mentioned in the Webmaster Tools FAQ as a valid option.
Guess this is the most up-to-date way of providing search engines some extra hypermedia breadcrumbs to follow - thus allow keeping you to keep them out of the response body when you don't actually need to serve it as content.
In addition to using 'Location' rather than 'Content-Location' use the proper HTTP status code in your response depending on your reason for redirect. Search engines tend to favor permanent redirect (301) status vs temporary (302) status.
Try the "Location:" header instead.