+ long ifModifiedSince = -1;
+ try {
+ ifModifiedSince = request.getDateHeader(HEADER_IF_MODIFIED_SINCE);
+ }
+ catch (Exception e) {
+ log.error("Exception while fetching If-Modified-Since: {}", e);
+ }
+
+ long lastModified = cacheable.getLastModified(request);
+
+ /**
+ * Sicherstellen, dass der Wert keine Millisekunden enthält, da die
+ * Zeitangabe aus dem Modified-Since-Header keine Millisekunden enthalten
+ * kann und der Test unten dann stets fehlschlagen würde!
+ */
+ lastModified = lastModified - (lastModified % 1000);
+
+ /**
+ * Cache-Control für HTTP/1.1-Clients generieren und setzen
+ *
+ * Nach {@plainlink http://tools.ietf.org/html/draft-ietf-httpbis-p4-conditional-18#section-4.1
+ * "HTTP/1.1, part 4: Conditional Requests",
+ * Abschnitt 4.1 "304 Not Modified" (Achtung: Entwurf -> work in progress!)}
+ * <strong>müssen</strong> die folgenden Felder in einer 304-Antwort
+ * enthalten sein, wenn sie auch in der ursprünglichen Antwort enthalten
+ * waren:
+ * <ul>
+ * <li>Cache-Control</li>
+ * <li>ETag</li>
+ * <li>Expires</li>
+ * <li>Last-Modified</li>
+ * <li>Vary</li>
+ * </ul>
+ */
+
+ /**
+ * Der Last-Modified-Header sollte (darf?) eventuell eigntlich nur für
+ * 200-Antworten gesetzt werden
+ * (s. http://webmasters.stackexchange.com/questions/25520/should-30)
+ *
+ * Da Squid sonst scheinbar nicht korrekt cached (und per if-not-modified
+ * aktualisiert) wird der Header aber trotzdem erst mal weiter erzeugt!
+ * (Ggf. noch mal prüfen, ob es eine Sinnestäuschung war, dass Squid
+ * Resourcen öfter als nötig komplett neu holt, wenn dieser Header fehlt!)
+ */
+ response.setDateHeader(HEADER_LAST_MODIFIED, lastModified);
+
+ Map<String, String> cacheControl = new HashMap<String, String>(cacheable.getCacheControl(request));
+
+ /**
+ * Wenn eins JSESSIONID in der URL enthalten ist, darf die Anfrage nur vom
+ * Browser gecached werden!
+ */
+ if (request.isRequestedSessionIdFromURL())
+ cacheControl.put("private", null);
+
+ if (cacheControl.containsKey("private")) {