Golang Static files (SVGZ) - http

Im trying to serve static .svgz files (compressed SVG) with the below script:
http.ListenAndServe(":9090", http.FileServer(http.Dir("/srv/www/htdocs/")))
im getting the below error:
This page contains the following errors:
error on line 1 at column 1: Encoding error
Below is a rendering of the page up to the first error.
if i try to fetch the same file through apache, the file is displaying properly.
is there a way to fix that?

The Go http.FileServer doesn't automatically add Content-Encoding for sniffed files. If the file is pre-compressed you will need to add the appropriate value.
You can add Content-Encoding: gzip to the headers and, and use http.ServeFile in your handler.

Apache Header (tested in Chrome):
HTTP/1.1 200 OK
Date: Fri, 24 Jun 2016 14:56:03 GMT
Server: Apache
Last-Modified: Fri, 24 Jun 2016 14:43:34 GMT
ETag: "443-5360731fd11b2"
Accept-Ranges: bytes
Content-Length: 1091
Keep-Alive: timeout=15, max=98
Connection: Keep-Alive
Content-Type: image/svg+xml
Content-Encoding: gzip
Go Header (tested in Chrome):
HTTP/1.1 200 OK
Accept-Ranges: bytes
Content-Length: 1091
Content-Type: image/svg+xml
Last-Modified: Fri, 24 Jun 2016 14:43:34 GMT
Date: Fri, 24 Jun 2016 14:54:56 GMT
Apache send "Content-Encoding: gzip" in header.
Working code (heavy inspired by https://groups.google.com/forum/#!topic/golang-nuts/Upzqsbu2zbo )
https://play.golang.org/p/eWxqHt9QbM

Related

NGINX treating SVG as Plain Text

I have a image I'm trying to load from SVG file. However, my mime.types file on my nginx server has the correct line present:
...
image/svg+xml svg svgz;
...
When I try to download the file, the server is saying it is plain text:
$ wget -O - -S http://172.22.253.119:2998/tw-logo-on-dark-2.svg > /dev/null
--2018-06-26 09:05:06-- http://172.22.253.119:2998/tw-logo-on-dark-2.svg
Connecting to 172.22.253.119:2998... connected.
HTTP request sent, awaiting response...
HTTP/1.1 200 OK
Server: nginx/1.13.12
Date: Tue, 26 Jun 2018 14:05:06 GMT
Content-Type: text/plain
Content-Length: 26706
Last-Modified: Mon, 25 Jun 2018 16:05:40 GMT
Connection: keep-alive
ETag: "5b3112d4-6852"
Accept-Ranges: bytes
Length: 26706 (26K) [text/plain]
Saving to: ‘STDOUT’
Can anyone tell me what I'm doing wrong?
The solution was to include this in my nginx.conf:
http {
include /etc/nginx/mime.types; # This includes the built in mime types
}

How does a HTTP/1.1 client know where a message ends in presence of `Connection: keep-alive` header field but absence of `Content-Length`?

In particular, I have this response header from an nginx server:
HTTP/1.1 200 OK
Server: nginx/1.10.3 (Ubuntu)
Date: Tue, 20 Mar 2018 10:28:24 GMT
Content-Type: text/html
Last-Modified: Thu, 28 Jan 2016 10:50:21 GMT
Connection: keep-alive
ETag: W/"56a9f26d-2d97"
Content-Encoding: gzip
Followed by some 3352 Bytes of compressed data. I'm trying to find out how does the client know where the body of this message ends and a new response begins.
It doesn't. The response requires either a Content-Length response header field, or it has to use "Transfer-Encoding: chunked".

IIS not returning HTTP/304 on conditional request made with If-None-Match

I have made a request for a video which returns a video with an ETAG.
When I make a request for the same video again, I can see the If-non-match header passed from the browser with the Etag but instead of 304 returned, the video is downloaded again with a 200 OK response.
In fiddler for the very first request for the video, the response is:
HTTP/1.1 200 OK
Cache-Control: max-age=10
Content-Length: 76278442
Content-Type: video/mp4
Last-Modified: Wed, 21 Aug 2013 08:47:29 GMT
ETag: "2117329216"
Server: Microsoft-IIS/7.5
X-Mod-H264-Streaming: version=2.2.7
X-Powered-By: ASP.NET
Date: Fri, 23 Aug 2013 21:20:34 GMT
On the second request, the GET headers are:
GET http://test/video.mp4 HTTP/1.1
Accept: */*
Accept-Language: en-GB
x-flash-version: 11,8,800,94
Accept-Encoding: gzip, deflate
If-Modified-Since: Wed, 21 Aug 2013 08:47:29 GMT
If-None-Match: "2117329216"
Connection: Keep-Alive
But in this case, I get the whole video downloaded rather than a 304 non modified response.
I noticed that X-Mod-H264-Streaming was used, not sure if this may have something to do with it.
Edit
I used the URL to the video in IE 10 directly (not using the flex application we were using before) and I get the same response where on the first request I get the complete video and after hitting f5 I get the whole video returned again rather than a 304 response.

Why is my browser doing a request if I've configured the expires and cache control headers?

This is an example response from my amazon bucket.
$ curl -I http://amazon_bucket/image.jpg
HTTP/1.1 200 OK
x-amz-id-2: Tmr9SynKe8ztlB/Jix1hNrclwyc/k4NVHyqK3B0vNKUoPFIxfzwALi0XQRwEjhzO
x-amz-request-id: DCFDBCF510988AFB
Date: Wed, 27 Mar 2013 13:06:34 GMT
Cache-Control: public, max-age=2629000
Expires: Wed, 26 Mar 2014 23:00:00 GMT
Last-Modified: Wed, 27 Mar 2013 13:00:19 GMT
ETag: "52dd53ea738c7824b3f67cfea6a3af2a"
Accept-Ranges: bytes
Content-Type: image/jpeg
Content-Length: 627046
Server: AmazonS3
I would expect the browser to cache the image and serve it from cache. Instead, when I reload the page, my browser does a request, which yield a 304 not modified response. Why is it acting like must-revalidate option was passed? Why isn't the browser serving the image directly from cache? The options I've configured on the image, from my S3 client are these:
Cache-Control: public, max-age=2629000
Expires: Wed, 26 Mar 2014 23:00:00 GMT
Is there some other option I should be passing to the S3 files? It might be a dumb answer, but I see that the requests my browser makes to get these pictures all have the following headers:
Cache-Control:no-cache
Pragma:no-cache
Why is my browser sending those?
I was hitting refresh, and apparently, this always triggers an If-Modified-Since request. If you visit the page normally, the asset is served from browser cache.

I suspect my website is sending wrong HTTP Headers

This has been bugging me for a while now. Whenever I try to share my website link on Facebook or another link-sharing site, the link-sharing site either removes the URL (like it doesn't recognize it as valid) or in Facebook's case - it can't retrieve meta-data automatically.
I'm pretty sure that it used to work. However, Googling / StackOverflowing for this problem is a difficult task, since I have no idea what possibly could create this problem.
I've tried to create a static .HTM file on my website, and that works fine:
test.htm
My default home page is a classic ASP (yeah I know, PHP version in the works) which uses IIS 7 URL Rewrite module.
I've tried to check the resultcodes and headers for both test.htm and my default home page on this page: http://gsitecrawler.com/tools/Server-Status.aspx
This is the results:
test.htm
URL=http://www.orango.nu/test.htm
Result code: 200 (OK / OK)
Content-Type: text/html
Last-Modified: Fri, 04 Feb 2011 10:16:55 GMT
Accept-Ranges: bytes
ETag: "0d877a654c4cb1:0"
Server: Microsoft-IIS/7.0
X-Powered-By: ASP.NET
Date: Fri, 04 Feb 2011 10:40:08 GMT
Content-Length: 452
default home page /
URL=http://www.orango.nu
Result code: 200 (OK / OK)
Cache-Control: public
Content-Length: 13463
Content-Type: text/html; Charset=UTF-8
Accept-Ranges: bytes
Server: Microsoft-IIS/7.0
Set-Cookie: ASPSESSIONIDSCSADCAR=DLPBECCBGDJMADLEPMOMHDDC; path=/
X-Powered-By: ASP.NET
Date: Fri, 04 Feb 2011 10:24:22 GMT
The first 4 lines of my default.asp (/) file are:
Response.ContentType = "text/html"
Response.AddHeader "Content-Type", "text/html;charset=UTF-8"
Response.CodePage = 65001
Response.CharSet = "UTF-8"
Does anyone have an idea what could be wrong and/or how to fix it? Any help or advice would be much appreciated, because this is driving me to the edge of madness.
The content-type looks wrong on your homepage...
HTTP/1.1 200 OK
Cache-Control: private
Content-Length: 13463
Content-Type: text/html;charset=UTF-8,text/html; Charset=UTF-8
Server: Microsoft-IIS/7.0
X-Powered-By: ASP.NET
Date: Fri, 04 Feb 2011 10:48:39 GMT
I also don't see the need, at least for the homepage, for the cache-control: private header.

Resources