-
Notifications
You must be signed in to change notification settings - Fork 95
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support last modified header #859
Conversation
Travis is happy. Ready for review again I believe 🎉 |
Thanks a lot! A couple of comments on the logic:
GlobalConfig.initializeConfig() already does a filemtime() call on
I think this should be not greater instead of greater? Anyways the code looks correct, no real issue here. |
Good idea! As it's using the cache, I think it should be safe to simply add that value to the cache in Just updated the branch to have that behaviour, so take a look at the latest commit here to see if what I did makes sense.
I got confused there for a minute, so had a look at Symfony's code to make sure I was not inverting the logic. Indeed a typo in the description, editing the issue description 👍 sorry for the confusion @osma |
Hmm, no, I don't think this makes sense. Right now, when APC is enabled, GlobalConfig checks the timestamp of Since we already need to check the timestamp on every request, passing it via APC to WebController is just overcomplicating things. I think GlobalConfig should simply check the |
Oh, yup, good point. If the cache was disabled we simply would never get that value re-used. Just re-read your previous comment, and you suggested a method to be created, but I hadn't understood why. Now it makes sense 👍 updating it in the next days. Thanks @osma ! |
6e827e7
to
b849502
Compare
Dropped last commit, then added a new one that
Rest of the workflow is the same. Unit test updated and passing on Travis, but another thorough review more than welcome (link to compare force-pushed commit above ^) Cheers |
Sorry for the delay in reviewing, once again... I think this is very close to be ready for merging, just a couple of probably minor observations:
|
Hi @osma !
Missed that one. Done!
I couldn't find this warning in the Docker images, even though they are running with Apache httpd and Apache 7.0. Might be some configuration that I am missing (tried the error_reporting(E_ALL) but nothing). However, when I opened the line reported in the warning in PyCharm, I noticed it had a warning. The PHP docstrings were stating that the function should return Thanks |
Great work @kinow! The warning is now gone. I will merge this to the |
Brilliant @osma! Let me know how it goes. If anything happens I'll try to amend my changes and fix whatever may be broken (hopefully nothing!) |
I've now enabled this for most vocabularies in http://dev.finto.fi . It seems to work fine so far. Concept pages that normally take 200-300ms to generate (or sometimes much more if they have LCSH and/or Wikidata mappings) now return a 304 response within 50ms on subsequent requests. I'm not seeing any new warnings in the Apache error log. |
Fix for #574 .
This pull request adds the support to the HTTP 304 Not Modified header in Skosmos.
Changes are mainly in
WebController
, for the method that handles displaying the concept information. The logic is as follow:config.ttl
hasskosmos:useModifiedDate = false
. Otherwise continue.getModifiedDate
to get the the modified date of the currentConcept
. It searches for theConcept
'sdc:modified
literal value.Concept
'sdc:modified
is not found, then it still tries to get thedc:modified
literal value of the main concept scheme (viaVocabulary::getDefaultConceptScheme()
, which should returnskosmos:mainConceptScheme
or the URI of the last concept scheme).getGitModifiedDate
, which executesgit log -1 --date=iso --pretty=format:%cd
and stores in the local cache for an intervalREAD_MODIFIED_CONFIG_TTL
of 10 minutes.getConfigModifiedDate
, which uses PHP's filemtime on theconfig.ttl
local file, retrieving the modification date and also storing in the local cache for the same intervalREAD_MODIFIED_CONFIG_TTL
of 10 minutes. NB: file modification dates depends on file system, operating system, and other settings.Last-Modified
header.If-Modified-Since
value in the HTTP Request headers, it means it understands HTTP 304. So we will compare the modified since from the browser with our most recent modified date. If our most recent modified date is not greater than the browser modified since date, then we end the request-response transaction with aHTTP/1.0 304 Not Modified
header.Unit tests included use mocking library to reach almost 100% coverage of the changes. Performed local tests using the
Dockerfile
in local environment, and two browsers with incognito mode and closing/opening the browsers to force cleaning the cache.This pull request covers the If-Modified-Since header. @osma, this pull request does not cover If-None-Match. I think this could be done later (involves
ETAG
's, coversHEAD
requests too) if necessary.Cheers
Bruno