I have graphite 0.9.10 on ubuntu 13. When I run the 'run-graphite-devel-server.py' script in the /opt/graphite/bin directory, the server comes up. However, when I access the url on port 8080, I receive the following (500 internal server) error:
SuspiciousOperation: Invalid HTTP_HOST header (you may need to set ALLOWED_HOSTS)
Any ideas on how to troubleshoot/resolve the issue.
Request headers:
Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding gzip, deflate
Accept-Language en-US,en;q=0.5
Connection keep-alive
Host 192.168.100.100:8080
User-Agent Mozilla/5.0 (Windows NT 6.1; WOW64; rv:25.0) Gecko/20100101 Firefox/25.0
Response Headers:
Content-Encoding gzip
Content-Length 592
Content-Type text/html; charset=utf-8
Date Thu, 12 Dec 2013 15:39:53 GMT
Server WSGIServer/0.1 Python/2.7.5+
Vary Accept-Encoding
Looks like you'll have to set access controls in graphite virtualhost file in your web-server. It might look like-
<Directory /opt/graphite/conf/>
Order deny,allow
Allow from all
</Directory>
If you're using apache, the file is by default at- /etc/httpd/conf.d/graphite-vhost.conf
The issue was resolved by adding the ALLOWED_HOSTS section in app_settings/settings.py in /opt/graphite/webapp/graphite. For instance (if local address is 192.168.100.100):
ALLOWED_HOSTS = ['localhost', '192.168.100.100']
Django appears to enforce the ALLOWED_HOSTS criteria. I was not able to make progress without this change. Hope it helps.
Related
Here is a question I have been researching for some time now.
I have a redirect that does not seem to be respecting a Set-Cookie attribute in a 302 Redirect.
Here are the request and response headers that I used wireshark to obtain.
HTTP/1.1 302 Moved Temporarily\r\n
Connection: close\r\n
Location: http://192.168.1.1:8888/home/\r\n
Set-Cookie: foo=test_data; Domain=192.168.1.1; Path=/\r\n
\r\n
GET /home/ HTTP/1.1\r\n
Host: 192.168.1.1:8888\r\n
Connection: keep-alive\r\n
Upgrade-Insecure-Requests: 1\r\n
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36\r\n
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8\r\n
Accept-Encoding: gzip, deflate\r\n
Accept-Language: en-US,en;q=0.8\r\n
DNT: 1\r\n
\r\n
I sanitized the content just a bit, but nothing critical should have been modified. The point is no matter the browser I use, the cookie 'foo' is not put in the GET request following the 302. From what I have read, this is not expected behavior. Am I incorrect in believing this? Is there something that I am missing or doing wrong with the 302?
In the question, Cookie header does not appear in the redirected HTTP request (GET http://192.168.1.1:8888/home). The root cause is: the cookie foo=test_data never exists. When it is delivered from server by Set-Cookie response header, it would be rejected by browser, as its Domain does not include the original server.
According to MDN:
A cookie belonging to a domain that does not include the origin server should be rejected by the user agent. The following cookie will be rejected if it was set by a server hosted on originalcompany.com.
Set-Cookie: qwerty=219ffwef9w0f; Domain=somecompany.co.uk; Path=/; Expires=Wed, 30 Aug 2019 00:00:00 GMT
For more accurate description, you can check RFC6265 section -4.1.2.3
This is designed with a good reason. If all server can Set-Cookie for all domain, it would be extremely easy to wipe out other website's cookie, which would be a disaster for internet.
I need to disable compression for atmosphere request headers. so instead of:
Accept-Encoding: gzip, deflate
I want to change this to:
Accept-Encoding: identity
Here's the headers from the request atmosphere.js creates:
Accept text/event-stream
Accept-Encoding gzip, deflate
Accept-Language en-US,en;q=0.5
Cache-Control no-cache
Connection keep-alive
Cookie JSESSIONID=791714A6221EEBBA
DNT 1
Host host
Pragma no-cache
Referer http://page url
User-Agent Mozilla/5.0 (Windows NT 6.1; WOW64; rv:32.0) Gecko/20100101 Firefox/32.0
I found in atmosphere documentation that you can specify headers:
headers [default = {}] A list of headers to send
But if I use this option:
headers={'Accept-Encoding':'identity'}
that gets passed as a request parameter- NOT a header.
Heres the request parameters that atmosphere.js creates:
Accept-Encoding identity
Content-Type application/json
X-Atmosphere-Framework 2.1.2-jquery
X-Atmosphere-Transport sse
X-Atmosphere-tracking-id 3a8f82b4-bbd9-48d8-907a-6e54ac94cbd6
X-Cache-Date 0
X-atmo-protocol true
Any ideas on how I can get Atmosphere to create requests without compression?
Just set request.attachHeadersAsQueryString = false
I am attempting to post to a page served by IIS6 and I am adding the following header:
Transfer-Encoding: chunked
When I do this, I get a 404 error: The system cannot find the file specified.. If I make the same request to the page without this header, it definitely exists.
Here are the headers - the only difference between the two requests is the chunking...
POST http://hostname/appname/index.html HTTP/1.1
Host: hostname
Connection: keep-alive
Transfer-Encoding: chunked
Cache-Control: max-age=0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.64 Safari/537.31
Content-Type: application/x-www-form-urlencoded
Referer: http://referrer/
And the body:
4
xxxx
0
The IIS metabase has AspEnableChunkedEncoding set to true at the W3SVC level and it is not overridden at the site level.
Why do I get a 404 error?
Update: I notice on the response for the unsuccessful request that the:
x-powered-by: asp.net
...header is absent. I don't know if that helps - it is there if I don't set the header in the request.
Is URLScan installed? It could be blocking the header
Using LiveHttpHeaders for Firefox 6 I was trying to see if my css, JS files being cached using Headers Module from Apache using htaccess. But I confuse, there are 2 values from the 'Cache-Control' data:
GET /proz/css/global.css HTTP/1.1
Host: localhost
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20100101 Firefox/5.0
Accept: text/css,*/*;q=0.1
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Referer: http://localhost/proz/
Cookie: PHPSESSID=el34de37pe3bnp4rdtbst1kd43
If-Modified-Since: Fri, 16 Sep 2011 21:15:32 GMT
If-None-Match: "400000000b06a-2999-4ad157e5b4583"
Cache-Control: max-age=0
HTTP/1.1 304 Not Modified
Date: Sat, 17 Sep 2011 03:04:50 GMT
Server: Apache/2.2.17 (Win32) PHP/5.2.8
Connection: Keep-Alive
Keep-Alive: timeout=5, max=99
Etag: "400000000b06a-2999-4ad157e5b4583"
Cache-Control: max-age=604800, public
Vary: Accept-Encoding
Which one is the true data, the first Cache-Control data (max-age=0) or the latter one.
I also would like to know how do I make sure that my JS, CSS, HTML files being compress after I use deflate module in htaccess. And yes, both headers and deflate modules are turn on.
There are two parts in this listing:
The part before the blank line is the request, sent by your browser
The part after the blank line is the response, sent by the server
The Cache-Control: max-age=0 sent by the client (your browser) tells the server (or any proxy in the middle) to send the most fresh version of the file. The browser usually sends this when you hit the refresh button.
The Cache-Control: max-age=604800, public sent by the server tells the client (your browser or a proxy) that the file is valid for 604800 seconds and can be cached for that time. (The browser won't even attemps to ask the server if a newer version exists, unless you hit refresh, as you did in this case.)
The server replied 304 Not Modified, this means that your browser already has the most recent version and it doesn't need to download it again (it did not downloaded it again).
The Vary: Accept-Encoding header indicate that the server taken some decisions based on the client's Accent-Encoding header. This may indicate that, if the server didn't replied 304 Not Modified, it would have compressed the file.
To verify this last point, clear your cache, and request the file again, and look at the content of the Content-Encoding header (must be gzip or deflate if the data is compressed).
I have a situation where my (embedded) web server is sending Expires header, but the browser does not seem to respect the header setting, i.e., if I refresh the page, the browser requests the resources that are supposed to be cached. Following are the headers that are getting exchanged:
https://192.168.1.180/scgi-bin/ajax/ajax.cgi
GET /scgi-bin/ajax/ajax.cgi HTTP/1.1
Host: 192.168.1.180
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.11) Gecko/2009060215 Firefox/3.0.11 (.NET CLR 3.5.30729)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Cache-Control: max-age=0
HTTP/1.x 200 OK
Date: Wed, 24 Jun 2009 20:26:47 GMT
Server: Embedded HTTP Server.
Connection: close
Content-Type: text/html
----------------------------------------------------------
https://192.168.1.180/scgi-bin/ajax/static.cgi?fn=images/logo.jpg&ts=20090624201057
GET /scgi-bin/ajax/static.cgi?fn=images/logo.jpg&ts=20090624201057 HTTP/1.1
Host: 192.168.1.180
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.11) Gecko/2009060215 Firefox/3.0.11 (.NET CLR 3.5.30729)
Accept: image/png,image/*;q=0.8,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: https://192.168.1.180/scgi-bin/ajax/ajax.cgi
Cache-Control: max-age=0
HTTP/1.x 200 OK
Date: Wed, 24 Jun 2009 20:26:47 GMT
Server: Embedded HTTP Server.
Connection: close
Expires: Wed, 1 Jun 2011 20:00:00 GMT
Content-Type: image/jpg
----------------------------------------------------------
The ajax.cgi returns an html page with a logo graphic (via the static.cgi script), which I'd like cached, but the browser is asking for the logo on every refresh.
The browser ignores the Expires header if you refresh the page. It always checks whether the cache entry is still valid by contacting the web server. Ideally, it will use the If-Modified-Since request header so that the server can return '304 Not modified' if the cache entry is still valid.
You're not setting the Last-Modified header, so the browser has to perform an unconditional GET of the content to ensure that it is up to date.
Some rules of thumb for setting Expires and Last-Modified are described in this blog post:
http://blog.httpwatch.com/2007/12/10/two-simple-rules-for-http-caching/
What are you doing in your browser? I looks like you click the reload button or even something like shift+Reload. Normally, the browser wouldn't send a Cache-Control: max-age=0 header. That means the browser has thrown away the cached image and wants to get it again.
If you just navigate to another page and then back again, the browser should respect your Expires header.
Additionally, you could add a Cache-control: public header to your response. That allows proxies and the browser explicitly to cache the image.
Any errors in your https certificate will cause the browser to not respect your headers.
Try it without https and see if it works over plain http.
See this answer https://stackoverflow.com/a/17716911
The CGI script looks like it has a timestamp parameter...this isn't changing, is it? The browser should be treating each unique URL as a different object in the cache, so if that is updating with every request, it won't match with the cached image.
Additionally, the Expires field is not exactly in RFC 1123 format, because you need two digits for the date. This may or may not be an issue, but it's something to check. The browser is including Cache-Control: max-age=0, which indicates that it believes its cache to be potentially out of date.
Once the server gets this validation request, it can return 304 (Not Modified), or 200 (OK), as it is doing currently.