Is there a HTTP header that makes sure that no content will be displayed?
Even if there is some content in the body?
edit:
I take the answers as a "no", and accept the fact that headers have no control over the content.
Send the status code 204 No Content.
Is there a HTTP header that makes sure that no content will be displayed?
The best way to make sure no content is displayed is not sending any content - you can never trust the client 100% to do what you want. That said, there is a status code that specifies exactly what you want:
10.2.5 204 No Content
The server has fulfilled the request but does not need to return an entity-body, and might want to return updated metainformation. The response MAY include new or updated metainformation in the form of entity-headers, which if present SHOULD be associated with the requested variant.
If the client is a user agent, it SHOULD NOT change its document view from that which caused the request to be sent. This response is primarily intended to allow input for actions to take place without causing a change to the user agent's active document view, although any new or updated metainformation SHOULD be applied to the document currently in the user agent's active view.
The 204 response MUST NOT include a message-body, and thus is always terminated by the first empty line after the header fields.
Related
Is it possible to provide HTTP header in browser's address bar?
e.g.
http://webpage.com/somepage.html [header1:value, header2:value]
My aim is testing different headers, but without scripting.
Why don't you simply use POSTMAN for it... It will allow you to send request of the type you want GET/POST/DELETE/PUT with whatever headers you expect to have.
For simple testing and checking of what content you get, you could select GET request and set the headers.
Here's a guide to using it
I am trying to use different background images from session to session. So if users open my website in a different session(e.g. Close and reopen the browser or wait for half an hour), they will see a different background image.
Following is what I am currently doing.
I created a HttpHandler class that handles background.axd.
First it checks whether there is an entry called BackgroundIndex in the HttpContext.Current.Session, if not, it randomly chooses a image from the ones that I have, than stores its index into the Session object.
Then it compares the index with the value of the If-None-Match header, if they match, simply return a response with 304 Not Modified.
If not match, or there isn't a 'If-None-Match' header in the request, it writes the content of the image file to the response and return it with ETag header set to the index of the image.
At last, I set the background image of my website to background.axd in my CSS file.
The problem is, it works correctly, but not efficiently.
The image file for current session can be loaded from cache. But if the session changes, the browser will have to download the image from my server even if it has been downloaded before.
Also, the browser has to make additional request to check if the image in cache has been out of date.
Is there a better solution for this?
Sorry for my bad English.
When building a RESTful HTTP service, and a Response is given with a 204 No Content (e.g. after the Consumer issues a DELETE Request), what Content-Type should the Response include?
Should it be omitted?
Is there a preferred Content-Type?
Should it be the same Content-Type of a GET Request to the same Resource?
Does it not matter whatsoever?
You have Content-Type when you have content and even then it's optional:
Any HTTP/1.1 message containing an entity-body SHOULD include a Content-Type header field defining the media type of that body.
(from RFC2616, ยง7.2.1, please note the use of SHOULD).
Since there is no content, then there is no reason to specify a Content-Type header.
Well, there's a little more to the story though, and it involves when the real-world (browsers) meet the theoretical world (specifications). Seems Firefox (ver 38 as I write this) has a bug where the browser attempts to parse the content as xml if there's no content-type header, EVEN WHEN the response code is 204 (no content). See https://bugzilla.mozilla.org/show_bug.cgi?id=521301
So, while a content type header doesn't make much sense when there's no content (and there MUST NOT be content on a 204) it seems to make sense to return some header anyway. And I don't see where that would be a violation of the spec.
I am going to describe my specific case below, but this might be useful to a number of web-mashups.
My web application POSTs to Twitter by filling a form and then submitting it (via javascript). The target of the form is set to an iframe which has an onload trigger. When the onload trigger is called the application knows that the POST was completed.
This used to work fine until Chrome version 11, which now respects the X-Frame-Options=SAMEORIGIN sent by Twitter in the POST response. The POST goes through, but the iframe's onload is not called anymore.
It still works in Firefox 4, but I suppose that's a bug that will eventually get fixed.
Is there any other way to know the status of the POST? I understand that knowing the contents of the POST response would violate the security policy, but I am not interested in the contents. I would just like the app to be notified when the POST is completed.
If you just need to know when the POST was submitted, and not necessarily whether it succeeded or not, you could poll the iframe's contentWindow and contentWindow.document on an interval. When you can no longer access one of those objects, or when the document has an empty body, that means that the iframe has loaded a page with X-Frame-Options restrictions, which likely means that the submission went through. It's hacky, but it looks like it will work for this purpose. (You'll probably have to go through a few combinations to figure out what the contents of restricted iframes look like in your target browsers.)
You can do it by getting the headers of the page. In php it will be looks like,
$url = 'http://www.google.com';
print_r(get_headers($url));
I need to load almost 100's of images in a single page on my website. ( product image, lots of them ). Whenever image change for product, url for that image also changes. i.e. for one url corresponding iamge never changes. Now I want to make sure that for a same person browsing through website, the image must not load again.
Is expire header is good enough ? ( sometime the browser still try to load it when refreshed manually )
on server side my python script always return 304 when if modified since header available without checking its value as each image has unique url. It normally works good but sometime when images are partially loaded and user move to another page, user see half downloaded images next time he land on the same page as server return 304. so how reliable if modified since header is ? and what are other alternative ?
Thanks.
edit 2:
what should be the content length for 304 response ? should it be the original content or actual content ( i.e. 0 ) ??
When you reload manually, most browsers disregard the caching headers, so this is normal and expected behavior.
The Expire header should be sufficient for this purpose.
As for the partial load, it can happen that the TCP connection gets broken while the image is loading; if you didn't specify Content-Length when sending the image, some browsers may assume that the connection was closed because all the data were sent. If Content-Length (a.k.a. image size in bytes) is specified, the browser should note when it doesn't have the complete image and will re-download it unconditionally the next time.
When sending the 304 Not Modified, it's not necessary to send Content-Length.