I visit the page http://furryfaust.com/waveform and it redirects to http://furyfaust.com/waveform/ with this initial response.
HTTP/1.1 301 Moved Permanently
Location: /waveform/
Date: Sat, 09 Jul 2016 21:32:56 GMT
Content-Length: 45
Content-Type: text/html; charset=utf-8
I found this out using chrome developer tools. I'm curious where the content-length is determined from since there is no response message body.
The page is served by a web framework called gin (https://github.com/gin-gonic/gin).
There is a content. The developer-tools don't show it for some reason, but using telnet I got the following response:
HTTP/1.1 301 Moved Permanently
Location: /waveform/
Date: Sat, 09 Jul 2016 21:40:38 GMT
Content-Length: 45
Content-Type: text/html; charset=utf-8
Moved Permanently.
Why the dev-tools don't show it? I don't know. Probably because Chrome doesn't even read the content because it'll redirect anyway.
Related
Bit of an odd one.
I noticed some query string stopped working on page load for a page on my website. Upon checking the network console of chrome and firefox, I can see that the page is returning a 403 forbidden error. This is odd, since the page seems to be loading correctly (except for query string not applying on page load).
It's the only page on the site that seems to be doing it.
Response Headers:
cache-control: no-cache, must-revalidate, max-age=0
cf-cache-status: MISS
cf-ray: 463904819f55a71f-DUB
content-encoding: br
content-type: text/html; charset=UTF-8
date: Tue, 02 Oct 2018 17:51:33 GMT
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
expires: Wed, 11 Jan 1984 05:00:00 GMT
link: <https://ygoprodeck.com/wp-json/>; rel="https://api.w.org/", <https://ygoprodeck.com/?p=7620>; rel=shortlink
pragma: no-cache
server: cloudflare
status: 403
vary: Accept-Encoding,Cookie,User-Agent
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
x-ua-compatible: IE=edge,chrome=1
x-xss-protection: 1; mode=block
I'm not sure how it can both get a 403 and load properly at the same time, very odd.
The page in question: https://ygoprodeck.com/deck-search/
Found the issue.
On the root of my site, I had a folder called "deck-search". No idea how it got there but it was causing issues. Removing it fixed it.
Im using yii framework with tiny mce. When I run my website in localhost it works just fine. But when I upload to the server the editor doesnt show up. when I check in Firebug, it show :
http://www.ptbm.co.id/veevou/assets/dde67fde/tiny_mce/tiny_mce_gzip.php?s=true&diskcache=true&core=t.......
then the status is 301 moved permanently
This is the request code :
// Send request
x = w.XMLHttpRequest ? new XMLHttpRequest() : get('Msxml2.XMLHTTP') || get('Microsoft.XMLHTTP');
x.overrideMimeType && x.overrideMimeType('text/javascript');
x.open('GET', t.baseURL + '/' + s.page_name + '?' + q, !!cb);
//x.setRequestHeader('Content-Type', 'text/javascript');
x.send('');
The url correctly pointing to existing file.
Anyone have any idea how to fix this? Thanks
Apparently your server redirects to a URL without the www prefix:
$ curl -I 'http://www.ptbm.co.id/veevou/assets/dde67fde/tiny_mce/tiny_mce_gzip.php?s=true&diskcache=true&core=t'
HTTP/1.1 301 Moved Permanently
Date: Fri, 18 Nov 2011 09:14:48 GMT
Server: Apache
X-Powered-By: PHP/5.3.8
X-Pingback: http://ptbm.co.id/xmlrpc.php
Expires: Wed, 11 Jan 1984 05:00:00 GMT
Cache-Control: no-cache, must-revalidate, max-age=0
Pragma: no-cache
Last-Modified: Fri, 18 Nov 2011 09:14:49 GMT
Location: http://ptbm.co.id/veevou/assets/dde67fde/tiny_mce/tiny_mce_gzip.php?s=true&diskcache=true&core=t
Content-Type: text/html; charset=UTF-8
You could remove that RewriteRule, or make sure that t.baseUrl does not have any www prefix.
Without more code it is difficult to give any more exact pointers than that.
I write a c program to crawl blogs. It works well until it meets this blog: www.ipujia.com. I send the HTTP request:
GET http://www.ipujia.com/ HTTP/1.0
to the website and get the response as below:
HTTP/1.1 301 Moved Permanently
Date: Sun, 27 Feb 2011 13:15:26 GMT
Server: Apache/2.2.16 (Unix) mod_ssl/2.2.16 OpenSSL/0.9.8e-fips-rhel5
mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635 mod_perl/2.0.4
Perl/v5.8.8
X-Powered-By: PHP/5.2.14
Expires: Wed, 11 Jan 1984 05:00:00 GMT
Cache-Control: no-cache, must-revalidate, max-age=0
Pragma: no-cache
Last-Modified: Sun, 27 Feb 2011 13:15:27 GMT
Location: http://http/www.ipujia.com/
Content-Length: 0
Connection: close
Content-Type: text/html; charset=UTF-8
This is strange because I cannot get the index page following the Location. Does anyone have any ideas?
The Location field in the response contains a malformed URI.
Location: http://http/www.ipujia.com/ (notice the protocol error)
Should be
Location: http://www.ipujia.com/
Unless you are in control of the server there is little you could do here.
To solve it could you not parse the "Location" response and attempt to extract a valid URI from the it?
I've run a couple tests and cannot get either a 301 or 302 redirect to be cached. In my case I have a large number of avatar icons on a page which I want redirected to a gravatar and/or facebook icon and I want the redirect to be cached, preferably for a medium period say a week.
Example header:
HTTP/1.1 301 Moved Permanently
Date: Sat, 27 Nov 2010 12:13:04 GMT
Server: Apache/2.2.3 (Red Hat)
Location: http://www.gravatar.com/avatar/552e3422df95ab611ce0d8d5b5d66c67?s=50&d=identicon
Cache-Control: max-age=414000
Expires: Thu, 02 Dec 2010 07:13:04 GMT
Content-Length: 330
Content-Type: text/html; charset=iso-8859-1
So is this possible and if so what am I doing wrong?
I understand you intention, but I doubt that browsers are caching 301 status responses (which is confirmed here). Reading your answer you have the HTML-content under your control. Why don't you just change the image-links inside your HTML-response? So instead working with 301 you already "migrate" the links inside the source-document and browser directly hits a 200 link.
I have some static content going through a CDN. I am using IIS6's built in compression (gzip & deflate) for static content and this is working fine when I request it. However, when the CDN makes the initial request for the content, it is not being returned compressed. They therefore don't have compressed content to forward to people requesting it. (Yes this raises the issue of people requesting [the zipped] content from the CDN with a browser that can't handle the compression. - We'll put that to one side for now though)
Here's an example of requesting without the 'Via' header:
HEAD /flash/swfobject.js HTTP/1.1
User-Agent: curl/7.19.7 (i386-pc-win32)
Host: localhost:9120
Accept: */*
Connection: Keep-Alive
accept-encoding: gzip
And it returns a compressed response:
HTTP/1.1 200 OK
Content-Length: 4357
Content-Type: application/x-javascript
Content-Encoding: gzip
Expires: Wed, 01 Jan 2020 00:00:00 GMT
Last-Modified: Wed, 18 Nov 2009 15:36:52 GMT
Accept-Ranges: bytes
Vary: Accept-Encoding
Server: Microsoft-IIS/6.0
Date: Thu, 19 Nov 2009 10:27:50 GMT
However, if I include a 'Via' header in the request (as the CDN does) then the result comes back uncompressed:
Request:
HEAD /flash/swfobject.js HTTP/1.1
User-Agent: curl/7.19.7 (i386-pc-win32)
Host: localhost:9120
Accept: */*
Connection: Keep-Alive
Via: 1.1 204.160.105.17:80 (Footprint 4.5/FPMCP)
accept-encoding: gzip
Response:
HTTP/1.1 200 OK
Content-Length: 14602
Content-Type: application/x-javascript
Expires: Wed, 01 Jan 2020 00:00:00 GMT
Last-Modified: Wed, 18 Nov 2009 15:36:54 GMT
Accept-Ranges: bytes
Server: Microsoft-IIS/6.0
Date: Thu, 19 Nov 2009 10:29:52 GMT
Yes these demos use 'localhost' in the request. I get the same result using the actual domain name from various machines on various networks though.
Two questions then:
Could this be IIS not applying the compression due to the extra header? and if so what can I do about it?
How can I tell if the proxy is decompressing the content before returning it?
Bonus question 3 - What can I do to investigate this problem further?
I am aware of question 332049, but that has the header in the response, not the request.
I stumbled across your question while researching this myself. I uncovered an article on MSDN and the short answer is that the Via header is used for proxies and proxies typically mess up compression. You either have the option of removing the header or you can change the setting in the IIS metabase (HcNoCompressionForProxies="FALSE"). I had success with both options.