If-Modified-Since vs. If-None-Match

http

The usual browser conditional request looks like this:

GET /i/yahoo.gif

HTTP/1.1 Host: us.yimg.com

If-Modified-Since: Tue, 12 Dec 2006 03:03:59 GMT

If-None-Match: "10c24bc-4ab-457e1c1f" HTTP/1.1

But what is the relation between If-Modified-Since and If-None-Match. OR? AND? So if any of them "fails", a new version will be sent?

Best Answer

http://www.ietf.org/rfc/rfc2616.txt

13.3.4 Rules for When to Use Entity Tags and Last-Modified Dates

An HTTP/1.1 origin server, upon receiving a conditional request that includes both a Last-Modified date (e.g., in an If-Modified-Since or If-Unmodified-Since header field) and one or more entity tags (e.g., in an If-Match, If-None-Match, or If-Range header field) as cache validators, MUST NOT return a response status of 304 (Not Modified) unless doing so is consistent with all of the conditional header fields in the request.
An HTTP/1.1 caching proxy, upon receiving a conditional request that includes both a Last-Modified date and one or more entity tags as cache validators, MUST NOT return a locally cached response to the client unless that cached response is consistent with all of the conditional header fields in the request.
- Note: The general principle behind these rules is that HTTP/1.1 servers and clients should transmit as much non-redundant information as is available in their responses and requests. HTTP/1.1 systems receiving this information will make the most conservative assumptions about the validators they receive.

Related Solutions

SMB administrative Shares (C$) not accessible on a server running SharePoint – WebDAV MiniRedir reports PROPFIND not implemented

It struck me that some of the services might be not running. I started the "Server" service using services.msc and UNC works again. So does the Visual Studio Remote Debugger. Hallelujah.

Iptables – redirect all incoming HTTPS traffic to another port

Why not use nginx instead?

server {
    listen 80;
    return 301 http://192.168.0.1:14901/$request_uri;
}

server {
    listen 443 ssl;
    return 301 https://192.168.0.1:14902/$request_uri;
}

But your cert probably isn't going to work without hostnames:

server {
    listen 80;
    server_name app1.example.com
    return 301 http://app1.example.com:14901/$request_uri;
}

server {
    listen 443 ssl;
    server_name app2.example.com
    return 301 https://app2.example.com:14902/$request_uri;
}

Use iptables to open ports 80 and 443 and let nginx do its thing.

iptables -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp -m tcp --dport 443 -j ACCEPT

If you need UDP, simply add

iptables -A INPUT -p udp -m udp --dport 80 -j ACCEPT
iptables -A INPUT -p udp -m udp --dport 443 -j ACCEPT

Best Answer

Related Solutions

SMB administrative Shares (C$) not accessible on a server running SharePoint – WebDAV MiniRedir reports PROPFIND not implemented

Iptables – redirect all incoming HTTPS traffic to another port

Related Topic