I am doing client side testing for my web application using IE only, there is no server - so I can test my CSS/XHTML/Javascript.
When I add the line
<link rel="icon" href="favicon1.ico"/>
or
<link rel="icon"href="favicon1.ico"type="image/x-icon"/>
or
<link rel="shortcut icon"href="favicon1.ico"type="image/x-icon"/>
or
<link rel="shortcut icon"href="file://favicon1.ico"type="image/x-icon"/>
I do not see my .ico image displayed in the tab.
My favicon1.ico is a 32px by 32px (32 bpp, 8-bit alpha, no pallete) .ico file created/saved in GIMP residing in the same directory as my html files.
Pretty convinced IE needs a server at this point. I'm trying somewhat random things and using trial and error. Is there a good documentation point for this?
This is temp fix per selected answer.
<link rel="shortcut icon"href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABQAAAAoCAYAAAD+MdrbAAAAAXNSR0IArs4c6QAAAAZiS0dEAP8A/wD/oL2nkwAAAAlwSFlzAAALEwAACxMBAJqcGAAAAAd0SU1FB9sHBRUfKj3fzL0AAAAdaVRYdENvbW1lbnQAAAAAAENyZWF0ZWQgd2l0aCBHSU1QZC5lBwAAAFVJREFUSMftzEEKACAIRFHrZHX/Q9kmKKJS013zYXbDS0TMFFim4AACBAgQIECAAH8Ea58mZmFl+hb5r8a0qAnToGZMQp+wG/qMnVAXtkPd2IqGYANt44KonPpHX24AAAAASUVORK5CYII="/>
Try using a data URI; convert an image using an online service like this one and use that for the href value.
<link rel="shortcut icon" href="data:image/gif;base64,R0lGODlhIAAgAOf/ADEzMDo0LjY2O9oNHS09P101P1c4NTBCR2A3KHQwO8QaK4otL88aJWw3LL4gJL4gKcAhH5osMT1HO8khKdIeLURGQ9wcJssiJCpOYNUhKVxEQ94gLklLSFNJTENOTnFIGk5ORsAvLWFLPmVLNcwwMzpYZrY3QURWYIBJPT1bUideeoJITU5VZ1pWVVtVXyJjhFxbU0xhSWVaStQ7PVtcZT1oTRlskkNjfAB1psJHOzJxR5tVTWplZLdSQGNndAB+tRqEPXBpUXJnaACBvllxXR6FRppgU1B5V1V5TMdYRGtwZwCGzMxXSySLQ8pYXF51hdZXUrNjWHd2XFmCYGOAZTmGpziQSS+TSn14ceFdWT6PT85kU4J7URePxzaSURqOzESOWrdtXjeWRzqZSb1vbaF/KJZ7elOSZclxXDSfTlGMtk6WXCyVzaKBONxsYchxbTiTxXiJdyaY1mmQZ0GfT0WUwkagSkCiWNl2ZD6nVV2eZEumUWecbWWeZcWAdDqg0kmqTF6iYVuZz0Ohx0esU3WaflWoWU6h3O9+d1CxUnCkdlOwWJudU0y1TpCbis+JhtuHeu2CeFil2pybd32kel6k4NeKgIGjiPODgFi1Y1q5WauhY2ur3G61c2K8Y2a7bbKgn5WskZKujG6y2/KUg7WnfG/AaMykmdyhirCrqXjDcs2vPpa2nc2yJdikkZ63kIjBg4bDe4G65cy1Spm+jtS4Nqa8nuWrnZC+5dS2b43Jhda6RZjEntS7Vcy8Z9u/NN6/NdG8gMLDh+HEMLLFsd/EQcXEldvFZ5vM5uLIUKHUmejKN7POstTIkq3RrOrML9rOeqfZpfDQKKjZq/TDuuvGvO7UK57Z8dzQlvHWIObPi+zUXMfXveHSpu3XU9jXlPbbJvTbR7fiuOLYpOrZg/vfHt/dk+ban/bhLeTZuPzgLvnjIMrixvXmIvziQPnlPObgsfTlV/nmR/XoR/rnUePkufvnYvnoafnocfbqfPHouvPsw//vqP/yt//2mJCRlCH+EUNyZWF0ZWQgd2l0aCBHSU1QACH5BAEKAP8ALAAAAAAgACAAAAj+AP8JHEiwoMGDCBMqXMiwoUOC1W6hQnWr2kOE1Pyg2cIkSZItW9A8snhR4KkeeB48cLByZYgQOd6ULCQCCgkGOC9cYEBhggIFEEw8hDUF1IwMGSZAiRTJTQgKGSxcmPCgIaxolFLNGJAFkpEVKHZYQnTBAgWpThby8jQtWpxHWfwUoPHEhwsDYUhZiLphgCuFnRZ9ikULFJkOL+ocEqRmCIsomDZItsAkITNDhDSp0uXIjIo/h0bJ4iSnSwcECRZEeDCjG0JFezKb0sUMho0uknBdkyVp0A1jpbjI0NCgDUI9dPYk8qSLV4XbuZHJkgPnxCZ86ML5GvEBYaAxdBL+aXYmQcUSOZxGVZJT5cAme+vKZStWxvsVOoCWs4vhwcaSL2x88UMJAYwzzzrgSPNMLcd5MYYdhDSizCUVpPACDj/ggIEAQfTTTjnoPDNMLfAcBMYVVqRBSCKLiBOHBAIQcAABAIAAzz3xWbNgKwiBocUVYtgR2yfiXKJECxVwIMU++cSX4DK1rPLaGk1YIQYdeRCSyStYYFGPPvzg42Q20oyYC0LcrFFEE1dckcYdc/AwiT/53CMPOuWUA441I86STkJ8rAEEm2JQIYQw+NhDz51OKvjLLr4oZMsZWgBRBBFYmHNPPPS8o8468WVjzaO9NLMQK31YUUQF38Qjjzxa74CKIJnAFFNqQ6HooYUOk8zjDjrqlDOriMn0EsxDtvDBRw2MxLqOOjouk0wyx2BTEjGiUHIEI/G4E44322xzDDQlliQQN6xcgoQw5JCjzTnmxivvvPTWW1JAADs=" />
I am trying to write an embedded application that serves it own web pages, and I'd like to get this working. However, I think I'm formatting the response incorrectly. Why is this not generating a fav icon in my browser tab (I'm guessing wrong Content-type or something similar):
curl -v localhost:7777/favicon.ico
* Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 7777 (#0)
> GET /favicon.ico HTTP/1.1
> Host: localhost:7777
> User-Agent: curl/7.43.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Content-Length: 1958
< Content-Type: text/html
<
* Connection #0 to host localhost left intact
<link rel="shortcut icon" href="data:image/gif;base64,R0lGODlhIAAgAOf/ADEzMDo0LjY2O9oNHS09P101P1c4NTBCR2A3KHQwO8QaK4otL88aJWw3LL4gJL4gKcAhH5osMT1HO8khKdIeLURGQ9wcJssiJCpOYNUhKVxEQ94gLklLSFNJTENOTnFIGk5ORsAvLWFLPmVLNcwwMzpYZrY3QURWYIBJPT1bUideeoJITU5VZ1pWVVtVXyJjhFxbU0xhSWVaStQ7PVtcZT1oTRlskkNjfAB1psJHOzJxR5tVTWplZLdSQGNndAB+tRqEPXBpUXJnaACBvllxXR6FRppgU1B5V1V5TMdYRGtwZwCGzMxXSySLQ8pYXF51hdZXUrNjWHd2XFmCYGOAZTmGpziQSS+TSn14ceFdWT6PT85kU4J7URePxzaSURqOzESOWrdtXjeWRzqZSb1vbaF/KJZ7elOSZclxXDSfTlGMtk6WXCyVzaKBONxsYchxbTiTxXiJdyaY1mmQZ0GfT0WUwkagSkCiWNl2ZD6nVV2eZEumUWecbWWeZcWAdDqg0kmqTF6iYVuZz0Ohx0esU3WaflWoWU6h3O9+d1CxUnCkdlOwWJudU0y1TpCbis+JhtuHeu2CeFil2pybd32kel6k4NeKgIGjiPODgFi1Y1q5WauhY2ur3G61c2K8Y2a7bbKgn5WskZKujG6y2/KUg7WnfG/AaMykmdyhirCrqXjDcs2vPpa2nc2yJdikkZ63kIjBg4bDe4G65cy1Spm+jtS4Nqa8nuWrnZC+5dS2b43Jhda6RZjEntS7Vcy8Z9u/NN6/NdG8gMLDh+HEMLLFsd/EQcXEldvFZ5vM5uLIUKHUmejKN7POstTIkq3RrOrML9rOeqfZpfDQKKjZq/TDuuvGvO7UK57Z8dzQlvHWIObPi+zUXMfXveHSpu3XU9jXlPbbJvTbR7fiuOLYpOrZg/vfHt/dk+ban/bhLeTZuPzgLvnjIMrixvXmIvziQPnlPObgsfTlV/nmR/XoR/rnUePkufvnYvnoafnocfbqfPHouvPsw//vqP/yt//2mJCRlCH+EUNyZWF0ZWQgd2l0aCBHSU1QACH5BAEKAP8ALAAAAAAgACAAAAj+AP8JHEiwoMGDCBMqXMiwoUOC1W6hQnWr2kOE1Pyg2cIkSZItW9A8snhR4KkeeB48cLByZYgQOd6ULCQCCgkGOC9cYEBhggIFEEw8hDUF1IwMGSZAiRTJTQgKGSxcmPCgIaxolFLNGJAFkpEVKHZYQnTBAgWpThby8jQtWpxHWfwUoPHEhwsDYUhZiLphgCuFnRZ9ikULFJkOL+ocEqRmCIsomDZItsAkITNDhDSp0uXIjIo/h0bJ4iSnSwcECRZEeDCjG0JFezKb0sUMho0uknBdkyVp0A1jpbjI0NCgDUI9dPYk8qSLV4XbuZHJkgPnxCZ86ML5GvEBYaAxdBL+aXYmQcUSOZxGVZJT5cAme+vKZStWxvsVOoCWs4vhwcaSL2x88UMJAYwzzzrgSPNMLcd5MYYdhDSizCUVpPACDj/ggIEAQfTTTjnoPDNMLfAcBMYVVqRBSCKLiBOHBAIQcAABAIAAzz3xWbNgKwiBocUVYtgR2yfiXKJECxVwIMU++cSX4DK1rPLaGk1YIQYdeRCSyStYYFGPPvzg42Q20oyYC0LcrFFEE1dckcYdc/AwiT/53CMPOuWUA441I86STkJ8rAEEm2JQIYQw+NhDz51OKvjLLr4oZMsZWgBRBBFYmHNPPPS8o8468WVjzaO9NLMQK31YUUQF38Qjjzxa74CKIJnAFFNqQ6HooYUOk8zjDjrqlDOriMn0EsxDtvDBRw2MxLqOOjouk0wyx2BTEjGiUHIEI/G4E44322xzDDQlliQQN6xcgoQw5JCjzTnmxivvvPTWW1JAADs=" />
Related
Raw details
Site: blog.helloenglish.com
IP: 107.22.249.42
Noticing the problem
Started to notice that all google caches, search metadata, webarchive pages, facebook link previews for blog.helloenglish.com have turned japanese.
I could not replicate the issue though. I have an Indian ISP (Airtel broadband) with Google DNS.
Only if I open the website via a US VPN (Tunnelbear, in my case), or use a VPS (EC2 instance in N. Virginia) to curl, I'm able to see the japanese site.
The website
Examining the site, it's some weird blog with posts about softwares, screwdrivers (yeah, actual screwdrivers. not even sonic), anchors, pliers, etc. I still have not found what website is this, but in the source it loads resources from bnote.net, which has a similar layout, is in japanese, and has similar posts. But the site I see on blog.helloenglish.com is different from bnote. Bnote behaves like an actual blog, focusing on softwares, each link referring to a post. But most of the links on blog.helloenglish.com are broken, with no href tags.
Opening any page on the domain opens up a different post in the japanese site. Examples:
http://blog.helloenglish.com/robots.txt
http://blog.helloenglish.com/manifest.xml
http://blog.helloenglish.com/helloworld
http://blog.helloenglish.com/foobar
Some screenshots here.
Some details about the infrastructure
Our setup is based on AWS completely.
The website is deployed using an Elasticbeanstalk application, hosted on EC2 Instances. The EC2 instance has the elastic IP 107.22.249.42. Our DNS Server is Route53 by AWS.
There's an A record there for blog.helloenglish.com with the value 107.22.249.42.
For the purpose of solving this problem, I've also set up an identical record for blog2.helloenglish.com. That domain has faced no issue.
The server has no virtual hosts.
curl
I'm ssh'ing into the blog's webserver now. I'll post the results from my ISP too.
VPS $ nslookup helloenglish.com
Server: 172.16.0.23
Address: 172.16.0.23#53
Non-authoritative answer:
Name: blog.helloenglish.com
Address: 107.22.249.42
MY_ISP $ nslookup blog.helloenglish.com
Server: 8.8.8.8
Address: 8.8.8.8#53
Non-authoritative answer:
Name: blog.helloenglish.com
Address: 107.22.249.42
The results for my PC and the VPS are the same.
Input:
VPS $ curl -v 107.22.249.42 --header 'Host: blog.helloenglish.com'
VPS $ curl -v blog.helloenglish.com
Output for all those commands:
* Rebuilt URL to: 107.22.249.42/
* Trying 107.22.249.42...
* Connected to 107.22.249.42 (107.22.249.42) port 80 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.40.0
> Accept: */*
> Host: blog.helloenglish.com
>
< HTTP/1.1 200 OK
< Date: Thu, 19 Jan 2017 06:08:17 GMT
< Server: Apache
< Transfer-Encoding: chunked
< Content-Type: text/html; charset=utf-8
<
<!DOCTYPE html>
<html lang="ja">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>2013春の新作,ファッション-その他</title>
<meta name="description" content="その他-城東テクノ Joto 高気密型床下点検口 (高断熱型450×600mm) フローリング15mm対応 ナチュラル (1セット) SPF-R45F15-BL2-NL,2013春の新作-ファッション" />
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta name="viewport" content="width=device-width, initial-scale=1">
<meta name="keywords" content="その他,2013春の新作,ファッション,人気blog" />
... (the japanese source)
----
Input:
MY_ISP $ curl -v 107.22.249.42 --header 'Host: blog.helloenglish.com'
MY_ISP $ curl -v blog.helloenglish.com
MY_ISP $ curl -v blog2.helloenglish.com
VPS $ curl -v blog2.helloenglish.com
VPS $ curl -v 107.22.249.42
VPS $ curl -v 107.22.249.42 --header 'Host: foobar'
VPS $ curl -v 127.0.0.1
VPS $ curl -v 127.0.0.1 --header 'Host: blog.helloenglish.com'
Output for all those commands:
* Rebuilt URL to: 107.22.249.42/
* Trying 107.22.249.42...
* TCP_NODELAY set
* Connected to 107.22.249.42 (107.22.249.42) port 80 (#0)
> GET / HTTP/1.1
> Host: blog.helloenglish.com
> User-Agent: curl/7.51.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Thu, 19 Jan 2017 06:08:02 GMT
< Server: Apache
< Link: <http://blog.helloenglish.com/wp-json/>; rel="https://api.w.org/"
< Transfer-Encoding: chunked
< Content-Type: text/html; charset=UTF-8
<
<!DOCTYPE html>
<!--[if IE 7]>
<html class="ie ie7" lang="en-US" prefix="og: http://ogp.me/ns#">
<![endif]-->
<!--[if IE 8]>
<html class="ie ie8" lang="en-US" prefix="og: http://ogp.me/ns#">
<![endif]-->
<!--[if !(IE 7) & !(IE 8)]><!-->
... (correct source)
Sending any other host apart from blog.helloenglish.com serves the correct site. It does make it sound like a vhosts problem, but it doesn't explain why I wouldn't see that on my PC.
It appears to me that it's a bug in how AWS forwards ElasticIPs. If it is, then it's a very serious and scary bug. Because the problem doesn't seem to be with route53, as curling the IP with host header reproduces the bug. curling the private IP of the instance doesn't reproduce it. I have no Idea what this has to do with the request coming from different zones though.
several servers serve a different website, depending on the Host header. it's basically what makes "shared hosting" so cheap, you can serve unlimited websites from a single ip/computer, all distinguished by the Host header.
try curl -v 107.22.249.42 --header 'Host: blog.helloenglish.com' , and you should get the same result
I am trying to build an HTTP server with an AVR + ESP8266.
I can send commands back and forth via telnet, but now I want to implement a web interface.
As a starting point I tried to setup a website that outputs "text"
however, the browser displays an empty page. Can someone please let me know the minimum requirements for the page to be interpreted as HTML?
telnet 192.168.2.26 81
Trying 192.168.2.26...
Connected to 192.168.2.26.
Escape character is '^]'.
GET / HTTP/1.1
AVR answer:
HTTP/1.1 200 OK
Content-Type: text/html
<!DOCTYPE html>
<html>
<head>
<meta content="text/html; charset=ISO-8859-1" http-equiv="content-type">
<title>Zeitschaltuhr</title></head>
<body>
Text
</body></html>
Connection closed by foreign host.
Minimal HTTP response:
HTTP/1.1 404
Content-Length: 0
Minimal response with content:
HTTP/1.1 200 OK
Content-Length: 12
Content-Type: text/plain; charset=utf-8
Hello World!
The reason it does not work for you is that you forgot the Content-Length: header.
Your HTTP response is missing the empty line between the response header fields and the message body (as explained here):
HTTP/1.1 200 OK
Content-Type: text/html
<!DOCTYPE html>
<html>
<head>
<meta content="text/html; charset=ISO-8859-1" http-equiv="content-type">
<title>Zeitschaltuhr</title></head>
<body>
Text
</body></html>
Important to provide twice CR,LF before content.
HTTP/1.1 200 OK\r\nContent-Length: 13\r\nContent-Type: text/html\r\n\r\nHello World!
Hopefully its just a quick one just ran my my first html validation everything worked exception it keeps telling me no content-type found. I've compared it to other html5 sites and I have no idea what's going on. I'm also getting a MIME error when I try to validate my CSS sheet. I'm pretty sure they're related/
http://validator.w3.org/check?uri=http%3A%2F%2Fnathansachs.com%2F&charset=%28detect+automatically%29&doctype=Inline&ss=1&group=0&user-agent=W3C_Validator%2F1.3+http%3A%2F%2Fvalidator.w3.org%2Fservices
As the error message says, your server is failing to include a Content-Type header in the HTTP response. This header is mandatory. It has nothing to do with the HTML document itself.
You need to fix your server or server side program that generates your content.
% curl -I http://nathansachs.com/
HTTP/1.1 200 OK
Date: Sat, 11 Jan 2014 09:24:50 GMT
Server: Apache mod_fcgid/2.3.10-dev
Last-Modified: Tue, 07 Jan 2014 20:32:26 GMT
ETag: "bec00cb-11d5-4ef674648e9f0"
Accept-Ranges: bytes
Content-Length: 4565
I'd consider upgrading Apache. You are using an older version of a development branch. That branch has stabilised and on revision 7 now! (i.e. Apache 2.4.7 is out). Use of experimental code might be the cause of your problem.
Possibly related:
Apache2 not sending “Content-Type” in header
Try to add this inside the <head /> section.
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
For HTML5:
<meta charset="UTF-8"> <!-- try without quotes as well -->
I got a problem with my server. I got four inbound links to different sites of my dynamic webpage which look something like this:
myurl.com/default/Site%3Fid%3D13
They should look like this:
myurl.com/default/Site?id=13
I do know that those %3F is an escape sequence for the ? sign and the %3D is an escape sequence for the equal sign. But I do get an error 400 when I use those links. What can I do about that?
The four links are for different sites, and I imagine over time there will be more links like that. So one fix for all would be perfect.
An exact same question was actually asked on nginx-ru mailing list about a year ago:
http://mailman.nginx.org/pipermail/nginx-ru/2013-February/050200.html
The most helpful response, by an Nginx, Inc, employee/developer, Валентин Бартенев:
http://mailman.nginx.org/pipermail/nginx-ru/2013-February/050209.html
Если запрос приходит в таком виде, то это уже не параметры, а имя запрошенного
файла. Другое дело, что location ищется по уже раскодированному адресу, о чем в
документации написано.
Translation:
If the request comes in such a form, then these are no longer the args, but the name of the requested file. Another thing is that, as documented, the location matching is performed against a normalised URI.
His suggested solution, translated to the sample example from the question here at SO, would then be:
location /default/Site? {
rewrite \?(.*)$ /default/Site?$1? last;
}
location = /default/Site {
[...]
}
The following sample would redirect all wrongly-looking requests (defined as having ? in the requested filename — encoded as %3F in the request) into less wrongly-looking ones, regardless of URL.
(Please note that, as rightly advised elsewhere, you should not be getting these wrongly-formed links in the first place, so, use it as a last resort — only when you cannot correct the wrongly formed links otherwise, and you do know that such requests are attempted by valid agents.)
server {
listen [::]:80;
server_name localhost;
rewrite ^/([^?]*)\?(.*)$ /$1?$2? permanent;
location / {
return 200 "id is $arg_id\n";
}
}
This is example of how it would work — when a wrongly looking request is encountered, a correction attempt is made with a 301 Moved Permanently response with a supposedly correct Location response header, which would make the browser automatically re-issue the request to the newly provided location:
opti# curl -6v "http://localhost/default/Site%3Fid%3D13"
* About to connect() to localhost port 80 (#0)
* Trying ::1...
* connected
* Connected to localhost (::1) port 80 (#0)
> GET /default/Site%3Fid%3D13 HTTP/1.1
> User-Agent: curl/7.26.0
> Host: localhost
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
< Server: nginx/1.4.1
< Date: Wed, 15 Jan 2014 17:09:25 GMT
< Content-Type: text/html
< Content-Length: 184
< Location: http://localhost/default/Site?id=13
< Connection: keep-alive
<
<html>
<head><title>301 Moved Permanently</title></head>
<body bgcolor="white">
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx/1.4.1</center>
</body>
</html>
* Connection #0 to host localhost left intact
* Closing connection #0
Note that no correction attempts are made on proper-looking requests:
opti# curl -6v "http://localhost/default/Site?id=13"
* About to connect() to localhost port 80 (#0)
* Trying ::1...
* connected
* Connected to localhost (::1) port 80 (#0)
> GET /default/Site?id=13 HTTP/1.1
> User-Agent: curl/7.26.0
> Host: localhost
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: nginx/1.4.1
< Date: Wed, 15 Jan 2014 17:09:30 GMT
< Content-Type: application/octet-stream
< Content-Length: 9
< Connection: keep-alive
<
id is 13
* Connection #0 to host localhost left intact
* Closing connection #0
The URL is perfectly valid. The escaped characters it contains are just that, escaped. Which is perfectly fine.
The purpose is that you can actually have a request name (in most cases corresponding to the filename on the disk) that is Site?id=13 and not Site and the rest as the query string.
I would consider it bad practice to have characters in a filename that makes this necessary. However, in URL arguments it may very well be necessary.
Nevertheless, the request URL is valid, and probably not what you want it to be. Which consequently suggest that you should correct the error wherever anybody has picked up the wrong URL in the first place.
I do not really understand why you get an error 400; you should rather get an error 404. But that depends on your setup.
There are also cases, especially with nginx, that mostly involve passing on whole URLs and URL parts along multiple levels (for example reverse proxies, matching regular expressions from the URL and using them as variables, etc.) where such an error may occur. But to verify this and fix it we would need to know more about your setup.
I added some settings on my HTML 5 Manifest which resulted perfect behavior on Google Chrome and
Safari on iOS and Safari as a web clip on iOS.
Unfortunately the same code results in abort on loading manifest files in IE and Fire Fox.
Here is the settings we applied:
In server side: IIS 7, Windows Server 2008 R2.
Response: text/cache-manifest , no-cache.
And the text of manifest is :
CACHE MANIFEST
CACHE:
/
/Index.html
/Login.html
/favicon.ico
/Content/Kendo/web/Font/FontAwesome.otf
NETWORK:
*
And here is the result of IE Network profiler for the first file
URL: http://192.168.0.220:1009/
Method:
Result: (Aborted)
Type: text/html
Received: 292 B
Taken: < 1 ms
Initiator: (Pending...)
And here is the response:
Key Value
Response HTTP/1.1 200 OK
Cache-Control no-cache, no-store
Pragma no-cache
Content-Type text/html
Expires -1
Last-Modified Mon, 23 Sep 2013 16:05:06 GMT
Accept-Ranges bytes
ETag "351169ab76b8ce1:0"
Server Microsoft-IIS/7.5
X-Powered-By ASP.NET
Date Mon, 23 Sep 2013 16:32:43 GMT
And this is a error message of html 5 manifest:
Resource doesn’t exist on the server: 'http://192.168.0.220:1009/'.
AppCache Fatal Error
And finally I've these meta tags on Index.html page:
<meta name="apple-mobile-web-app-capable" content="yes" />
<meta name="apple-mobile-web-app-status-bar-style" content="black" />
<meta http-equiv="CACHE-CONTROL" content="NO-CACHE" />
<meta http-equiv="EXPIRES" content="0" />
<meta http-equiv="PRAGMA" content="NO-CACHE" />
Any help highly appreciated.
I've found a reason for the problem.
In Request_End in ASP.NET Global.asax we should apply
HttpContext.Current.Response.Cache.SetNoStore();
only for iOS, and chrome is always working, both for updating application and for offline usage.
Note: no-store is needed in web clip and safari of iOS, because of files which are already loaded before updating manifest, else they won't be updated, even when manifest downloads new version of them.
Hope this helps you too.