I want to remove http response header in mvc.
HTTP/1.1 404 Not Found Cache-Control: private Content-Type: text/html;
charst=utf-8 Server: Microsoft-IIS/8.0 X-Powered-By: ASP.NET Date:
Mon, 23 Feb 2015 12:43:58 GMT Content-Length: 4898 Connection:
Keep-Alive
I remove Connection, X-Powered-By, Server, Cache-Control with this code:
> protected void Application_PreSendRequestHeaders(object sender,EventArgs e)
> {
> HttpContext.Current.Response.Headers.Remove("X-Powered-By");
> HttpContext.Current.Response.Headers.Remove("X-AspNet-Version");
> HttpContext.Current.Response.Headers.Remove("X-AspNetMvc-Version");
> HttpContext.Current.Response.Headers.Remove("Server");
> HttpContext.Current.Response.Headers.Remove("Cache-Control");
> }
but how can i do remove all http response header?
Please update your question with more information on the reasons driving you to remove those headers, since this looks to me as a quite unusual need, especially for content-type. It may turn out you need to do something else.
Otherwise, read on.
Try with IISRewrite module. It should allow you to get them blank.
See this answer or this more detailed one.
If removing them is really what you require, you may have to write your own custom isapi filter. There is some information about this solution on this other answer.
For many of them, you may also consider disabling what adds them rather than removing them after they have been added. See my answer on this subject for a bunch of them.
Related
I am working with rails, and returning a json response with the below method
def return_json
render json: params
end
When i am viewing the response on chrome developers tools, everything seems to be right. But when i trace the HTTP response on wireshark, on HTTP response body it seems that some extra characters exists.
HTTP/1.1 200 OK
Server: nginx/1.10.3
Date: Wed, 05 Jul 2017 17:07:48 GMT
Content-Type: application/json; charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
Cache-Control: max-age=0, private, must-revalidate
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
X-Runtime: 0.433854
X-Request-Id: f46a0e87-6969-4285-9b80-da0223edac01
X-Powered-By: Phusion Passenger 5.1.5
Status: 200 OK
49
{"device_attributes":[{"id":"85","value":"35"},{"id":"80","value":"65"}]}
0
(extra empty line)
I'm talking about the number 49 which is in hex and it seems to be the length of the JSON string. And after that it follows a 0 with an empty line.
Wireshark screenshot which shows the response
First of all, i would like to ask, what a valid HTTP response look like?
I think that after headers, follows an empty line and then the response body and after that nothing.
And second why rails do that and if there is a way to change that. I think that rails do that, because i get the same response from apache + phusion passenger and also puma. Also i tried this from some other code, not related to rails, and the HTTP response it was as i explained earlier and not as rails does.
I did not found out the answer i was looking for, but a workaround in order for the extra info to be removed, is to render as follows:
render plain: ActiveSupport::JSON.encode({ result: :ok })
This work around does set content-type as 'text/plain' and not 'application/json'. If you set content-type in render options as 'application/json' this extra info are being displayed again.
So i will assume that has something to do with the json renderer module, but i can't research it more at this time.
I'm receiving invalid characters on try to receiving JSON by http protocol in C.
When I send
GET /<query> http/1.1\r\nHost:<host>\r\n\r\n
then the result displays as follow:
HTTP/1.0 200 OK
Cache-Control: private
Content-Type: application/json; charset=utf-8
Content-Encoding: gzip
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, POST
Access-Control-Allow-Credentials: false
X-Content-Type-Options: nosniff
Date: Sun, 07 Dec 2014 13:14:29 GMT
Content-Length: 11410
�
I don't know why I don't receiving JSON? However, in browser's address bar I type the same query & I received the json as well.
[UPDATE # 1]
I found it useful to work on built-in library, as the error is related to network byte compressions so I used Qt's library QNetworkManager specifically to done this job.
Please use a HTTP library or make yourself comfortable with the HTTP protocol and implement it properly.
Content-Encoding: gzip
At least this line means trouble for your simple parsing. But interestingly, based on your request the server should not sent this line if a non-compressed version is available. This means not only your code is buggy, but that the server might be buggy too (it actually assume that you understand any compressions because you did not say different).
GET / http/1.1\r\nHost:\r\n\r\n
And your request is wrong too. It must be HTTP/1.1 instead of http/1.1. And it must contain a proper host header.
Qt's QNetworkManager is best for this purpose, as it do all the intricate stuff itself & provide elegant interface to user.
I have a web page that returns the following header when I access material:
HTTP/1.1 200 OK
Date: Sat, 29 Jun 2013 15:57:25 GMT
Server: Apache
Content-Length: 2247515
Cache-Control: no-cache, no-store, must-revalidate, max-age=-1
Pragma: no-cache, no-store
Expires: -1
Connection: close
Using a chrome extension, I want to modify this response header so that the material is actually cached instead of wasting bandwidth.
I have the following sample code:
chrome.webRequest.onHeadersReceived.addListener(function(details)
{
// Delete the required elements
removeHeader(details.responseHeaders, 'pragma');
removeHeader(details.responseHeaders, 'expires');
// Modify cache-control
updateHeader(details.responseHeaders, 'cache-control', 'max-age=3600;')
console.log(details.url);
console.log(details.responseHeaders);
return{responseHeaders: details.responseHeaders};
},
{urls: ["<all_urls>"]}, ['blocking', 'responseHeaders']
);
Which correctly modifies the header to something like this (based on the console.log() output):
HTTP/1.1 200 OK
Date: Sat, 29 Jun 2013 15:57:25 GMT
Server: Apache
Content-Length: 2247515
Cache-Control: max-age=3600
Connection: close
But based on everything I have tried to check this, I cannot see any evidence whatsoever that this has actually happened:
The cache does not contain an entry for this file
The Network tab in the Developer Console shows no change at all to the HTTP response (I have tried changing it to even trivial modifications just for the sake of ensuring that its not a error, but still no change).
The only real hints I can find are this question which suggests that my approach still works and this paragraph on the webRequest API documentation which suggests that this won't work (but doesn't explain why I can't get any changes whatsoever):
Note that the web request API presents an abstraction of the network
stack to the extension. Internally, one URL request can be split into
several HTTP requests (for example to fetch individual byte ranges
from a large file) or can be handled by the network stack without
communicating with the network. For this reason, the API does not
provide the final HTTP headers that are sent to the network. For
example, all headers that are related to caching are invisible to the
extension.
Nothing is working whatsoever (I can't modify the HTTP response header at all) so I think that's my first concern.
Any suggestions at where I could be going wrong or how to go about finding what is going wrong here?
If its not possible, are there any other ways to achieve what I am trying to achieve?
I have recently spent some hours on trying to get a file cached, and discovered that the chrome.webRequest and chrome.declarativeWebRequest APIs cannot force resources to be cached. In no way.
The Cache-Control (and other) response headers can be changed, but it will only be visible in the getResponseHeader method. Not in the caching behaviour.
Im starting experimenting with Wikimedia, but I somehow can't get the login request working with a HTTP Client (RESTClient Firefox and others). This should be fairly simple, but it seems to fail or I have overlooked something evident.
I am using the instructions from this site.
This is what I insert in RESTClient:
I don't get the MediaWiki API Result back, but the help page (see below).
What am I doing wrong here? Thanks for any input.
Status Code: 200 OK
Cache-Control: private
Connection: keep-alive
Content-Encoding: gzip
Content-Length: 38052
Content-Type: text/html; charset=utf-8
Date: Mon, 09 Jul 2012 11:50:51 GMT
MediaWiki-API-Error: help
Server: Apache
Vary: Accept-Encoding
X-Cache: MISS from sq33.wikimedia.org, MISS from amssq35.esams.wikimedia.org, MISS from amssq39.esams.wikimedia.org
X-Cache-Lookup: MISS from sq33.wikimedia.org:3128, MISS from amssq35.esams.wikimedia.org:3128, MISS from amssq39.esams.wikimedia.org:80
X-Content-Type-Options: nosniff
<!DOCTYPE HTML>
<html>
<head>
<title>MediaWiki API</title>
</head>
<body>
<pre>
<span style="color:blue;"><?xml version="1.0"?></span>
<span style="color:blue;"><api servedby="mw67"></span>
<span style="color:blue;"><error code="help" info=""
xml:space="preserve"></span>
The are two problems with your request:
You're using the wrong URL. The correct domain is en.wikipedia.org, not www.wikipedia.org.
It seems RESTClient is using the Content-Type of text/plain by default, but the API expects application/x-www-form-urlencoded.
If you correct those two problems, you will get the correct response.
You also might want to indicate in what format do you want the response, by adding format=xml or format=json to the request. The default is HTML-formatted XML, which is useful for showing in a browser, but not for consumption by your application.
I've never seen this before, I've always known there was either GET or POST. And I can't find any good documentation.
GET send variables via the URL.
POST send it via the file body?
What does HEAD do?
It doesn't get used often, am I correct?
W3schools.com doesn't even mention it.
HTML’s method attribute only allows GET and POST.
The HEAD method is used to send the request and retrieve just the HTTP header as response. For example, a client application can issue a HEAD request to check the size of a file (from HTTP headers) without downloading it. As Arjan points out, it's not even valid in HTML forms.
HTTP method HEAD sends the response's headers but without a body; it's often useful, as the URL I've given explains, though hardly ever in a "form" HTML tag.
The only thing I can imagine is that the server may actually have been set up to validate the request method, to discover submissions by robots that for HEAD might actually use a different method than a browser does. (And thus reject those submissions.)
A response to a HEAD request does not imply nothing is shown to the user: even a response to HEAD can very well redirect to another page. However, like Gumbo noted: it's not valid for the method in a HTML form, so this would require a lot of testing in each possible browser...
For a moment I wondered if HEAD in a form is somehow used to avoid accidental multiple submissions. But I assume the only useful response would be a 301 Redirect, but that could also be used with GET or POST, so I don't see how HEAD would solve any issues.
A quick test in the current versions of both Safari and Firefox on a Mac shows that actually a GET is invoked. Of course, assuming this is undocumented behavior, one should not rely on that. Maybe for some time, spam robots were in fact fooled into using HEAD (which would then be rejected on the server), or might be fooled into skipping this form if they would only support GET and POST. But even the dumbest robot programmer (aren't they all dumb for not understanding their work is evil?) would soon have learned that a browser converts this into GET.
(Do you have an example of a website that uses this? Are you sure there's no JavaScript that changes this, or does something else? Can anyone test what Internet Explorer sends?)
HEAD Method
The HEAD method is functionally like GET, except that the server replies with a response line and headers, but no entity-body. Following is a simple example which makes use of HEAD method to fetch header information about hello.htm:
HEAD /hello.htm HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
Following will be a server response against the above GET request:
HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: "34aa387-d-1568eb00"
Vary: Authorization,Accept
Accept-Ranges: bytes
Content-Length: 88
Content-Type: text/html
Connection: Closed
You can notice that here server does not send any data after header.
-Obtained from tutorialspoint.com