I'm looking at the performance of the UI in the web browser, and I noticed that the HTML, CSS and PNG files are cached, but the browser is going to back to the server for JavaScript files. A typical CSS request returns these headers: Cache-Control:max-age=2592000 Connection:Keep-Alive Content-Encoding:gzip Content-Length:14512 Content-Type:text/css;charset=UTF-8 Date:Thu, 12 May 2016 16:03:23 GMT Keep-Alive:timeout=5, max=99 Server:Apache-Coyote/1.1 Strict-Transport-Security:max-age=15768000 Vary:Accept-Encoding While a JavaScript request returns these headers Connection:Keep-Alive Content-Encoding:gzip Content-Type:application/javascript;charset=UTF-8 Date:Thu, 12 May 2016 15:59:17 GMT Keep-Alive:timeout=5, max=97 Server:Apache-Coyote/1.1 Strict-Transport-Security:max-age=15768000 Transfer-Encoding:chunked Vary:Accept-Encoding Note the lack of a Cache-Control header in the JavaScript file. I have Apache as a proxy in front of the Tomcat instance (to handle the initial redirect to the tenant login URL and to do the SSL processing), so I think I can force Apache to add a Cache-Control header to the response. I just don't know if there are any consequences to doing that. As an aside, I did try using Google's mod_pagespeed to concatenate-and-minify CSS and JS files, but that went horribly awry -- probably something to do with the dynamic loading of the various parts of the page. Other thoughts? Peter -- Peter Murray Dev/Ops Lead and Project Manager Cherry Hill Company

1. Cache-Control:
max-age=2592000
2. Connection:
Keep-Alive
3. Content-Encoding:
gzip
4. Content-Length:
14512
5. Content-Type:
text/css;charset=UTF-8
6. Date:
Thu, 12 May 2016 16:03:23 GMT
7. Keep-Alive:
timeout=5, max=99
8. Server:
Apache-Coyote/1.1
9. Strict-Transport-Security:
max-age=15768000
10. Vary:
Accept-Encoding

1. Connection:
Keep-Alive
2. Content-Encoding:
gzip
3. Content-Type:
application/javascript;charset=UTF-8
4. Date:
Thu, 12 May 2016 15:59:17 GMT
5. Keep-Alive:
timeout=5, max=97
6. Server:
Apache-Coyote/1.1
7. Strict-Transport-Security:
max-age=15768000
8. Transfer-Encoding:
chunked
9. Vary:
Accept-Encoding

Hi Peter, To answer your second question: There's a poorly documented way to use a built-in tool for minimizing the UI js & css assets found on this wiki page: https://wiki.collectionspace.org/pages/viewpage.action?pageId=77824080 The default UI web resource optimization (wro) file is outdated so you will need to make a few changes to it and the ui pom.xml and src/build.xml files. I have a recent commit that documents my tenant-specific changes to get the minimization build script to work. https://github.com/OaklandMuseum/ui/commit/3d186e4f07efa6b46feed5a59174bd7e8a634c96 FYI, The build tool will complain about syntax in a few files -- a trailing comma after the last element in an array/object. Jesse On Thu, May 12, 2016 at 12:09 PM, Peter Murray <pmurray@chillco.com> wrote: > I'm looking at the performance of the UI in the web browser, and I noticed > that the HTML, CSS and PNG files are cached, but the browser is going to > back to the server for JavaScript files. A typical CSS request returns > these headers: > > > 1. Cache-Control: > max-age=2592000 > 2. Connection: > Keep-Alive > 3. Content-Encoding: > gzip > 4. Content-Length: > 14512 > 5. Content-Type: > text/css;charset=UTF-8 > 6. Date: > Thu, 12 May 2016 16:03:23 GMT > 7. Keep-Alive: > timeout=5, max=99 > 8. Server: > Apache-Coyote/1.1 > 9. Strict-Transport-Security: > max-age=15768000 > 10. Vary: > Accept-Encoding > > > While a JavaScript request returns these headers > > > 1. Connection: > Keep-Alive > 2. Content-Encoding: > gzip > 3. Content-Type: > application/javascript;charset=UTF-8 > 4. Date: > Thu, 12 May 2016 15:59:17 GMT > 5. Keep-Alive: > timeout=5, max=97 > 6. Server: > Apache-Coyote/1.1 > 7. Strict-Transport-Security: > max-age=15768000 > 8. Transfer-Encoding: > chunked > 9. Vary: > Accept-Encoding > > > Note the lack of a Cache-Control header in the JavaScript file. I have > Apache as a proxy in front of the Tomcat instance (to handle the initial > redirect to the tenant login URL and to do the SSL processing), so I think > I can force Apache to add a Cache-Control header to the response. I just > don't know if there are any consequences to doing that. > > As an aside, I did try using Google's mod_pagespeed to > concatenate-and-minify CSS and JS files, but that went horribly awry -- > probably something to do with the dynamic loading of the various parts of > the page. > > Other thoughts? > > > Peter > -- > Peter Murray > Dev/Ops Lead and Project Manager > Cherry Hill Company > > > _______________________________________________ > Talk mailing list > Talk@lists.collectionspace.org > > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org > >

1. Cache-Control:
max-age=2592000
2. Connection:
Keep-Alive
3. Content-Encoding:
gzip
4. Content-Length:
14512
5. Content-Type:
text/css;charset=UTF-8
6. Date:
Thu, 12 May 2016 16:03:23 GMT
7. Keep-Alive:
timeout=5, max=99
8. Server:
Apache-Coyote/1.1
9. Strict-Transport-Security:
max-age=15768000
10. Vary:
Accept-Encoding

1. Connection:
Keep-Alive
2. Content-Encoding:
gzip
3. Content-Type:
application/javascript;charset=UTF-8
4. Date:
Thu, 12 May 2016 15:59:17 GMT
5. Keep-Alive:
timeout=5, max=97
6. Server:
Apache-Coyote/1.1
7. Strict-Transport-Security:
max-age=15768000
8. Transfer-Encoding:
chunked
9. Vary:
Accept-Encoding

JS files should have the Cache-Control header set according to ui-js-cache-timeout in your app layer settings.xml. This is working on our 4.1 installations, but I notice it's not working on 4.3. It seems like something broke in between. Ray On Thu, May 12, 2016 at 9:53 AM, Jesse Martinez <mjesse@gmail.com> wrote: > Hi Peter, > > To answer your second question: There's a poorly documented way to use a > built-in tool for minimizing the UI js & css assets found on this wiki > page: > https://wiki.collectionspace.org/pages/viewpage.action?pageId=77824080 > > The default UI web resource optimization (wro) file is outdated so you > will need to make a few changes to it and the ui pom.xml and src/build.xml > files. I have a recent commit that documents my tenant-specific changes to > get the minimization build script to work. > > > https://github.com/OaklandMuseum/ui/commit/3d186e4f07efa6b46feed5a59174bd7e8a634c96 > > FYI, The build tool will complain about syntax in a few files -- a > trailing comma after the last element in an array/object. > > Jesse > > > > On Thu, May 12, 2016 at 12:09 PM, Peter Murray <pmurray@chillco.com> > wrote: > >> I'm looking at the performance of the UI in the web browser, and I >> noticed that the HTML, CSS and PNG files are cached, but the browser is >> going to back to the server for JavaScript files. A typical CSS request >> returns these headers: >> >> >> 1. Cache-Control: >> max-age=2592000 >> 2. Connection: >> Keep-Alive >> 3. Content-Encoding: >> gzip >> 4. Content-Length: >> 14512 >> 5. Content-Type: >> text/css;charset=UTF-8 >> 6. Date: >> Thu, 12 May 2016 16:03:23 GMT >> 7. Keep-Alive: >> timeout=5, max=99 >> 8. Server: >> Apache-Coyote/1.1 >> 9. Strict-Transport-Security: >> max-age=15768000 >> 10. Vary: >> Accept-Encoding >> >> >> While a JavaScript request returns these headers >> >> >> 1. Connection: >> Keep-Alive >> 2. Content-Encoding: >> gzip >> 3. Content-Type: >> application/javascript;charset=UTF-8 >> 4. Date: >> Thu, 12 May 2016 15:59:17 GMT >> 5. Keep-Alive: >> timeout=5, max=97 >> 6. Server: >> Apache-Coyote/1.1 >> 7. Strict-Transport-Security: >> max-age=15768000 >> 8. Transfer-Encoding: >> chunked >> 9. Vary: >> Accept-Encoding >> >> >> Note the lack of a Cache-Control header in the JavaScript file. I have >> Apache as a proxy in front of the Tomcat instance (to handle the initial >> redirect to the tenant login URL and to do the SSL processing), so I think >> I can force Apache to add a Cache-Control header to the response. I just >> don't know if there are any consequences to doing that. >> >> As an aside, I did try using Google's mod_pagespeed to >> concatenate-and-minify CSS and JS files, but that went horribly awry -- >> probably something to do with the dynamic loading of the various parts of >> the page. >> >> Other thoughts? >> >> >> Peter >> -- >> Peter Murray >> Dev/Ops Lead and Project Manager >> Cherry Hill Company >> >> >> _______________________________________________ >> Talk mailing list >> Talk@lists.collectionspace.org >> >> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >> >> > > _______________________________________________ > Talk mailing list > Talk@lists.collectionspace.org > > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org > >

1. Cache-Control:
max-age=2592000
2. Connection:
Keep-Alive
3. Content-Encoding:
gzip
4. Content-Length:
14512
5. Content-Type:
text/css;charset=UTF-8
6. Date:
Thu, 12 May 2016 16:03:23 GMT
7. Keep-Alive:
timeout=5, max=99
8. Server:
Apache-Coyote/1.1
9. Strict-Transport-Security:
max-age=15768000
10. Vary:
Accept-Encoding

1. Connection:
Keep-Alive
2. Content-Encoding:
gzip
3. Content-Type:
application/javascript;charset=UTF-8
4. Date:
Thu, 12 May 2016 15:59:17 GMT
5. Keep-Alive:
timeout=5, max=97
6. Server:
Apache-Coyote/1.1
7. Strict-Transport-Security:
max-age=15768000
8. Transfer-Encoding:
chunked
9. Vary:
Accept-Encoding

Oh, this broke with the upgrade to Tomcat 7. Tomcat 6 set the mime type for JS files to "text/javascript", but Tomcat 7 sets it to "application/javascript". The app layer continues to look for "text/javascript" to apply the cache control header. Ray On Thu, May 12, 2016 at 1:09 PM, Ray Lee <rhlee@berkeley.edu> wrote: > JS files should have the Cache-Control header set according > to ui-js-cache-timeout in your app layer settings.xml. This is working on > our 4.1 installations, but I notice it's not working on 4.3. It seems like > something broke in between. > > Ray > > On Thu, May 12, 2016 at 9:53 AM, Jesse Martinez <mjesse@gmail.com> wrote: > >> Hi Peter, >> >> To answer your second question: There's a poorly documented way to use a >> built-in tool for minimizing the UI js & css assets found on this wiki >> page: >> https://wiki.collectionspace.org/pages/viewpage.action?pageId=77824080 >> >> The default UI web resource optimization (wro) file is outdated so you >> will need to make a few changes to it and the ui pom.xml and src/build.xml >> files. I have a recent commit that documents my tenant-specific changes to >> get the minimization build script to work. >> >> >> https://github.com/OaklandMuseum/ui/commit/3d186e4f07efa6b46feed5a59174bd7e8a634c96 >> >> FYI, The build tool will complain about syntax in a few files -- a >> trailing comma after the last element in an array/object. >> >> Jesse >> >> >> >> On Thu, May 12, 2016 at 12:09 PM, Peter Murray <pmurray@chillco.com> >> wrote: >> >>> I'm looking at the performance of the UI in the web browser, and I >>> noticed that the HTML, CSS and PNG files are cached, but the browser is >>> going to back to the server for JavaScript files. A typical CSS request >>> returns these headers: >>> >>> >>> 1. Cache-Control: >>> max-age=2592000 >>> 2. Connection: >>> Keep-Alive >>> 3. Content-Encoding: >>> gzip >>> 4. Content-Length: >>> 14512 >>> 5. Content-Type: >>> text/css;charset=UTF-8 >>> 6. Date: >>> Thu, 12 May 2016 16:03:23 GMT >>> 7. Keep-Alive: >>> timeout=5, max=99 >>> 8. Server: >>> Apache-Coyote/1.1 >>> 9. Strict-Transport-Security: >>> max-age=15768000 >>> 10. Vary: >>> Accept-Encoding >>> >>> >>> While a JavaScript request returns these headers >>> >>> >>> 1. Connection: >>> Keep-Alive >>> 2. Content-Encoding: >>> gzip >>> 3. Content-Type: >>> application/javascript;charset=UTF-8 >>> 4. Date: >>> Thu, 12 May 2016 15:59:17 GMT >>> 5. Keep-Alive: >>> timeout=5, max=97 >>> 6. Server: >>> Apache-Coyote/1.1 >>> 7. Strict-Transport-Security: >>> max-age=15768000 >>> 8. Transfer-Encoding: >>> chunked >>> 9. Vary: >>> Accept-Encoding >>> >>> >>> Note the lack of a Cache-Control header in the JavaScript file. I have >>> Apache as a proxy in front of the Tomcat instance (to handle the initial >>> redirect to the tenant login URL and to do the SSL processing), so I think >>> I can force Apache to add a Cache-Control header to the response. I just >>> don't know if there are any consequences to doing that. >>> >>> As an aside, I did try using Google's mod_pagespeed to >>> concatenate-and-minify CSS and JS files, but that went horribly awry -- >>> probably something to do with the dynamic loading of the various parts of >>> the page. >>> >>> Other thoughts? >>> >>> >>> Peter >>> -- >>> Peter Murray >>> Dev/Ops Lead and Project Manager >>> Cherry Hill Company >>> >>> >>> _______________________________________________ >>> Talk mailing list >>> Talk@lists.collectionspace.org >>> >>> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >>> >>> >> >> _______________________________________________ >> Talk mailing list >> Talk@lists.collectionspace.org >> >> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org >> >> >

Thank you, Jesse -- most helpful. I started with a patch file from the GitHub commit: https://github.com/OaklandMuseum/ui/commit/3d186e4f07efa6b46feed5a59174bd7e8a634c96.patch <https://github.com/OaklandMuseum/ui/commit/3d186e4f07efa6b46feed5a59174bd7e8a634c96.patch> Then I edited it to replace some of the tenant-specific file names in the WRO -- I have not made nearly the same number of customizations there than are in OMCA. I also replaced the tenant name where it was specified in the patch. I applied the patch to the source directory with `patch -p 1` and cleaned up a few instances where patch couldn't automatically modify the source code. Then I ran `mvn -Pminimize,tomcat clean install` on the source directory and tried it out. So far the tests on my vagrant machine are much improved. I'll try it on the production server over the weekend. Ray: I couldn't tell if your observation that the 'app layer continues to look for "text/javascript" to apply the cache control header' meant that this was a bug in the code or a change in the configuration. Jira ticket? Peter > On May 12, 2016, at 12:53 PM, Jesse Martinez <mjesse@gmail.com <mailto:mjesse@gmail.com>> wrote: > > Hi Peter, > > To answer your second question: There's a poorly documented way to use a built-in tool for minimizing the UI js & css assets found on this wiki page: https://wiki.collectionspace.org/pages/viewpage.action?pageId=77824080 <https://wiki.collectionspace.org/pages/viewpage.action?pageId=77824080> > > The default UI web resource optimization (wro) file is outdated so you will need to make a few changes to it and the ui pom.xml and src/build.xml files. I have a recent commit that documents my tenant-specific changes to get the minimization build script to work. > > https://github.com/OaklandMuseum/ui/commit/3d186e4f07efa6b46feed5a59174bd7e8a634c96 <https://github.com/OaklandMuseum/ui/commit/3d186e4f07efa6b46feed5a59174bd7e8a634c96> > > FYI, The build tool will complain about syntax in a few files -- a trailing comma after the last element in an array/object. > > Jesse > > > > On Thu, May 12, 2016 at 12:09 PM, Peter Murray <pmurray@chillco.com <mailto:pmurray@chillco.com>> wrote: > I'm looking at the performance of the UI in the web browser, and I noticed that the HTML, CSS and PNG files are cached, but the browser is going to back to the server for JavaScript files. A typical CSS request returns these headers: > > Cache-Control:max-age=2592000 > Connection:Keep-Alive > Content-Encoding:gzip > Content-Length:14512 > Content-Type:text/css;charset=UTF-8 > Date:Thu, 12 May 2016 16:03:23 GMT > Keep-Alive:timeout=5, max=99 > Server:Apache-Coyote/1.1 > Strict-Transport-Security:max-age=15768000 > Vary:Accept-Encoding > > While a JavaScript request returns these headers > > Connection:Keep-Alive > Content-Encoding:gzip > Content-Type:application/javascript;charset=UTF-8 > Date:Thu, 12 May 2016 15:59:17 GMT > Keep-Alive:timeout=5, max=97 > Server:Apache-Coyote/1.1 > Strict-Transport-Security:max-age=15768000 > Transfer-Encoding:chunked > Vary:Accept-Encoding > > Note the lack of a Cache-Control header in the JavaScript file. I have Apache as a proxy in front of the Tomcat instance (to handle the initial redirect to the tenant login URL and to do the SSL processing), so I think I can force Apache to add a Cache-Control header to the response. I just don't know if there are any consequences to doing that. > > As an aside, I did try using Google's mod_pagespeed to concatenate-and-minify CSS and JS files, but that went horribly awry -- probably something to do with the dynamic loading of the various parts of the page. > > Other thoughts? > > > Peter -- Peter Murray Dev/Ops Lead and Project Manager Cherry Hill Company

1. Cache-Control:
max-age=2592000
2. Connection:
Keep-Alive
3. Content-Encoding:
gzip
4. Content-Length:
14512
5. Content-Type:
text/css;charset=UTF-8
6. Date:
Thu, 12 May 2016 16:03:23 GMT
7. Keep-Alive:
timeout=5, max=99
8. Server:
Apache-Coyote/1.1
9. Strict-Transport-Security:
max-age=15768000
10. Vary:
Accept-Encoding

1. Connection:
Keep-Alive
2. Content-Encoding:
gzip
3. Content-Type:
application/javascript;charset=UTF-8
4. Date:
Thu, 12 May 2016 15:59:17 GMT
5. Keep-Alive:
timeout=5, max=97
6. Server:
Apache-Coyote/1.1
7. Strict-Transport-Security:
max-age=15768000
8. Transfer-Encoding:
chunked
9. Vary:
Accept-Encoding

It's a bug in code: https://github.com/collectionspace/application/blob/master/tomcat-main/src/main/java/org/collectionspace/chain/controller/TenantServlet.java#L416 I don't think there's a JIRA issue, but I didn't search for one. Could you create one? The bug looks easy to fix, if you want to make a pull request. Thanks, Ray On Fri, May 13, 2016 at 9:16 AM, Peter Murray <pmurray@chillco.com> wrote: > Thank you, Jesse -- most helpful. I started with a patch file from the > GitHub commit: > > > https://github.com/OaklandMuseum/ui/commit/3d186e4f07efa6b46feed5a59174bd7e8a634c96.patch > > Then I edited it to replace some of the tenant-specific file names in the > WRO -- I have not made nearly the same number of customizations there than > are in OMCA. I also replaced the tenant name where it was specified in the > patch. I applied the patch to the source directory with `patch -p 1` and > cleaned up a few instances where patch couldn't automatically modify the > source code. Then I ran `mvn -Pminimize,tomcat clean install` on the > source directory and tried it out. So far the tests on my vagrant machine > are much improved. I'll try it on the production server over the weekend. > > Ray: I couldn't tell if your observation that the 'app layer continues to > look for "text/javascript" to apply the cache control header' meant that > this was a bug in the code or a change in the configuration. Jira ticket? > > > Peter > > > On May 12, 2016, at 12:53 PM, Jesse Martinez <mjesse@gmail.com> wrote: > > Hi Peter, > > To answer your second question: There's a poorly documented way to use a > built-in tool for minimizing the UI js & css assets found on this wiki > page: > https://wiki.collectionspace.org/pages/viewpage.action?pageId=77824080 > > The default UI web resource optimization (wro) file is outdated so you > will need to make a few changes to it and the ui pom.xml and src/build.xml > files. I have a recent commit that documents my tenant-specific changes to > get the minimization build script to work. > > > https://github.com/OaklandMuseum/ui/commit/3d186e4f07efa6b46feed5a59174bd7e8a634c96 > > FYI, The build tool will complain about syntax in a few files -- a > trailing comma after the last element in an array/object. > > Jesse > > > > On Thu, May 12, 2016 at 12:09 PM, Peter Murray <pmurray@chillco.com> > wrote: > >> I'm looking at the performance of the UI in the web browser, and I >> noticed that the HTML, CSS and PNG files are cached, but the browser is >> going to back to the server for JavaScript files. A typical CSS request >> returns these headers: >> >> >> 1. Cache-Control: >> max-age=2592000 >> 2. Connection: >> Keep-Alive >> 3. Content-Encoding: >> gzip >> 4. Content-Length: >> 14512 >> 5. Content-Type: >> text/css;charset=UTF-8 >> 6. Date: >> Thu, 12 May 2016 16:03:23 GMT >> 7. Keep-Alive: >> timeout=5, max=99 >> 8. Server: >> Apache-Coyote/1.1 >> 9. Strict-Transport-Security: >> max-age=15768000 >> 10. Vary: >> Accept-Encoding >> >> >> While a JavaScript request returns these headers >> >> >> 1. Connection: >> Keep-Alive >> 2. Content-Encoding: >> gzip >> 3. Content-Type: >> application/javascript;charset=UTF-8 >> 4. Date: >> Thu, 12 May 2016 15:59:17 GMT >> 5. Keep-Alive: >> timeout=5, max=97 >> 6. Server: >> Apache-Coyote/1.1 >> 7. Strict-Transport-Security: >> max-age=15768000 >> 8. Transfer-Encoding: >> chunked >> 9. Vary: >> Accept-Encoding >> >> >> Note the lack of a Cache-Control header in the JavaScript file. I have >> Apache as a proxy in front of the Tomcat instance (to handle the initial >> redirect to the tenant login URL and to do the SSL processing), so I think >> I can force Apache to add a Cache-Control header to the response. I just >> don't know if there are any consequences to doing that. >> >> As an aside, I did try using Google's mod_pagespeed to >> concatenate-and-minify CSS and JS files, but that went horribly awry -- >> probably something to do with the dynamic loading of the various parts of >> the page. >> >> Other thoughts? >> >> >> Peter >> > > > -- > Peter Murray > Dev/Ops Lead and Project Manager > Cherry Hill Company > > > > _______________________________________________ > Talk mailing list > Talk@lists.collectionspace.org > > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org > >

Thanks for the clarification, Ray. I see that Aron created an issue last week (https://issues.collectionspace.org/browse/CSPACE-6952 <https://issues.collectionspace.org/browse/CSPACE-6952> -- thanks, Aron). I might have time to work on this tomorrow or Thursday; I'll have to see how other work proceeds. A process question: the fix is likely to be the same for 4.2, 4.3, and HEAD. Should I make three pull requests against the three branches? I've already got a custom branch of 4.2 that I'm working from, so it would only benefit others that are working from the official branches. Peter > On May 13, 2016, at 2:33 PM, Ray Lee <rhlee@berkeley.edu <mailto:rhlee@berkeley.edu>> wrote: > > It's a bug in code: https://github.com/collectionspace/application/blob/master/tomcat-main/src/main/java/org/collectionspace/chain/controller/TenantServlet.java#L416 <https://github.com/collectionspace/application/blob/master/tomcat-main/src/main/java/org/collectionspace/chain/controller/TenantServlet.java#L416> > > I don't think there's a JIRA issue, but I didn't search for one. Could you create one? The bug looks easy to fix, if you want to make a pull request. > > Thanks, > Ray > > > On Fri, May 13, 2016 at 9:16 AM, Peter Murray <pmurray@chillco.com <mailto:pmurray@chillco.com>> wrote: > Thank you, Jesse -- most helpful. I started with a patch file from the GitHub commit: > > https://github.com/OaklandMuseum/ui/commit/3d186e4f07efa6b46feed5a59174bd7e8a634c96.patch <https://github.com/OaklandMuseum/ui/commit/3d186e4f07efa6b46feed5a59174bd7e8a634c96.patch> > > Then I edited it to replace some of the tenant-specific file names in the WRO -- I have not made nearly the same number of customizations there than are in OMCA. I also replaced the tenant name where it was specified in the patch. I applied the patch to the source directory with `patch -p 1` and cleaned up a few instances where patch couldn't automatically modify the source code. Then I ran `mvn -Pminimize,tomcat clean install` on the source directory and tried it out. So far the tests on my vagrant machine are much improved. I'll try it on the production server over the weekend. > > Ray: I couldn't tell if your observation that the 'app layer continues to look for "text/javascript" to apply the cache control header' meant that this was a bug in the code or a change in the configuration. Jira ticket? > > > Peter > > >> On May 12, 2016, at 12:53 PM, Jesse Martinez <mjesse@gmail.com <mailto:mjesse@gmail.com>> wrote: >> >> Hi Peter, >> >> To answer your second question: There's a poorly documented way to use a built-in tool for minimizing the UI js & css assets found on this wiki page: https://wiki.collectionspace.org/pages/viewpage.action?pageId=77824080 <https://wiki.collectionspace.org/pages/viewpage.action?pageId=77824080> >> >> The default UI web resource optimization (wro) file is outdated so you will need to make a few changes to it and the ui pom.xml and src/build.xml files. I have a recent commit that documents my tenant-specific changes to get the minimization build script to work. >> >> https://github.com/OaklandMuseum/ui/commit/3d186e4f07efa6b46feed5a59174bd7e8a634c96 <https://github.com/OaklandMuseum/ui/commit/3d186e4f07efa6b46feed5a59174bd7e8a634c96> >> >> FYI, The build tool will complain about syntax in a few files -- a trailing comma after the last element in an array/object. >> >> Jesse >> >> >> >> On Thu, May 12, 2016 at 12:09 PM, Peter Murray <pmurray@chillco.com <mailto:pmurray@chillco.com>> wrote: >> I'm looking at the performance of the UI in the web browser, and I noticed that the HTML, CSS and PNG files are cached, but the browser is going to back to the server for JavaScript files. A typical CSS request returns these headers: >> >> Cache-Control:max-age=2592000 >> Connection:Keep-Alive >> Content-Encoding:gzip >> Content-Length:14512 >> Content-Type:text/css;charset=UTF-8 >> Date:Thu, 12 May 2016 16:03:23 GMT >> Keep-Alive:timeout=5, max=99 >> Server:Apache-Coyote/1.1 >> Strict-Transport-Security:max-age=15768000 >> Vary:Accept-Encoding >> >> While a JavaScript request returns these headers >> >> Connection:Keep-Alive >> Content-Encoding:gzip >> Content-Type:application/javascript;charset=UTF-8 >> Date:Thu, 12 May 2016 15:59:17 GMT >> Keep-Alive:timeout=5, max=97 >> Server:Apache-Coyote/1.1 >> Strict-Transport-Security:max-age=15768000 >> Transfer-Encoding:chunked >> Vary:Accept-Encoding >> >> Note the lack of a Cache-Control header in the JavaScript file. I have Apache as a proxy in front of the Tomcat instance (to handle the initial redirect to the tenant login URL and to do the SSL processing), so I think I can force Apache to add a Cache-Control header to the response. I just don't know if there are any consequences to doing that. >> >> As an aside, I did try using Google's mod_pagespeed to concatenate-and-minify CSS and JS files, but that went horribly awry -- probably something to do with the dynamic loading of the various parts of the page. >> >> Other thoughts? >> >> >> Peter -- Peter Murray Dev/Ops Lead and Project Manager Cherry Hill Company

1. Cache-Control:
max-age=2592000
2. Connection:
Keep-Alive
3. Content-Encoding:
gzip
4. Content-Length:
14512
5. Content-Type:
text/css;charset=UTF-8
6. Date:
Thu, 12 May 2016 16:03:23 GMT
7. Keep-Alive:
timeout=5, max=99
8. Server:
Apache-Coyote/1.1
9. Strict-Transport-Security:
max-age=15768000
10. Vary:
Accept-Encoding

1. Connection:
Keep-Alive
2. Content-Encoding:
gzip
3. Content-Type:
application/javascript;charset=UTF-8
4. Date:
Thu, 12 May 2016 15:59:17 GMT
5. Keep-Alive:
timeout=5, max=97
6. Server:
Apache-Coyote/1.1
7. Strict-Transport-Security:
max-age=15768000
8. Transfer-Encoding:
chunked
9. Vary:
Accept-Encoding

Hi Peter, Against master for sure, so the fix makes it into the next release. Whether it needs to go into the 4.2 and 4.3 branches is up to Richard and the community. It seems to me that it's a safe change to make to those branches, so I say go for it if you have time. Thanks, Ray On Mon, May 16, 2016 at 8:22 AM, Peter Murray <pmurray@chillco.com> wrote: > Thanks for the clarification, Ray. I see that Aron created an issue last > week (https://issues.collectionspace.org/browse/CSPACE-6952 -- thanks, > Aron). I might have time to work on this tomorrow or Thursday; I'll have > to see how other work proceeds. > > A process question: the fix is likely to be the same for 4.2, 4.3, and > HEAD. Should I make three pull requests against the three branches? I've > already got a custom branch of 4.2 that I'm working from, so it would only > benefit others that are working from the official branches. > > > Peter > > On May 13, 2016, at 2:33 PM, Ray Lee <rhlee@berkeley.edu> wrote: > > It's a bug in code: > https://github.com/collectionspace/application/blob/master/tomcat-main/src/main/java/org/collectionspace/chain/controller/TenantServlet.java#L416 > > I don't think there's a JIRA issue, but I didn't search for one. Could you > create one? The bug looks easy to fix, if you want to make a pull request. > > Thanks, > Ray > > > On Fri, May 13, 2016 at 9:16 AM, Peter Murray <pmurray@chillco.com> wrote: > >> Thank you, Jesse -- most helpful. I started with a patch file from the >> GitHub commit: >> >> >> https://github.com/OaklandMuseum/ui/commit/3d186e4f07efa6b46feed5a59174bd7e8a634c96.patch >> >> Then I edited it to replace some of the tenant-specific file names in the >> WRO -- I have not made nearly the same number of customizations there than >> are in OMCA. I also replaced the tenant name where it was specified in the >> patch. I applied the patch to the source directory with `patch -p 1` and >> cleaned up a few instances where patch couldn't automatically modify the >> source code. Then I ran `mvn -Pminimize,tomcat clean install` on the >> source directory and tried it out. So far the tests on my vagrant machine >> are much improved. I'll try it on the production server over the weekend. >> >> Ray: I couldn't tell if your observation that the 'app layer continues to >> look for "text/javascript" to apply the cache control header' meant that >> this was a bug in the code or a change in the configuration. Jira ticket? >> >> >> Peter >> >> >> On May 12, 2016, at 12:53 PM, Jesse Martinez <mjesse@gmail.com> wrote: >> >> Hi Peter, >> >> To answer your second question: There's a poorly documented way to use a >> built-in tool for minimizing the UI js & css assets found on this wiki >> page: >> https://wiki.collectionspace.org/pages/viewpage.action?pageId=77824080 >> >> The default UI web resource optimization (wro) file is outdated so you >> will need to make a few changes to it and the ui pom.xml and src/build.xml >> files. I have a recent commit that documents my tenant-specific changes to >> get the minimization build script to work. >> >> >> https://github.com/OaklandMuseum/ui/commit/3d186e4f07efa6b46feed5a59174bd7e8a634c96 >> >> FYI, The build tool will complain about syntax in a few files -- a >> trailing comma after the last element in an array/object. >> >> Jesse >> >> >> >> On Thu, May 12, 2016 at 12:09 PM, Peter Murray <pmurray@chillco.com> >> wrote: >> >>> I'm looking at the performance of the UI in the web browser, and I >>> noticed that the HTML, CSS and PNG files are cached, but the browser is >>> going to back to the server for JavaScript files. A typical CSS request >>> returns these headers: >>> >>> >>> 1. Cache-Control: >>> max-age=2592000 >>> 2. Connection: >>> Keep-Alive >>> 3. Content-Encoding: >>> gzip >>> 4. Content-Length: >>> 14512 >>> 5. Content-Type: >>> text/css;charset=UTF-8 >>> 6. Date: >>> Thu, 12 May 2016 16:03:23 GMT >>> 7. Keep-Alive: >>> timeout=5, max=99 >>> 8. Server: >>> Apache-Coyote/1.1 >>> 9. Strict-Transport-Security: >>> max-age=15768000 >>> 10. Vary: >>> Accept-Encoding >>> >>> >>> While a JavaScript request returns these headers >>> >>> >>> 1. Connection: >>> Keep-Alive >>> 2. Content-Encoding: >>> gzip >>> 3. Content-Type: >>> application/javascript;charset=UTF-8 >>> 4. Date: >>> Thu, 12 May 2016 15:59:17 GMT >>> 5. Keep-Alive: >>> timeout=5, max=97 >>> 6. Server: >>> Apache-Coyote/1.1 >>> 7. Strict-Transport-Security: >>> max-age=15768000 >>> 8. Transfer-Encoding: >>> chunked >>> 9. Vary: >>> Accept-Encoding >>> >>> >>> Note the lack of a Cache-Control header in the JavaScript file. I have >>> Apache as a proxy in front of the Tomcat instance (to handle the initial >>> redirect to the tenant login URL and to do the SSL processing), so I think >>> I can force Apache to add a Cache-Control header to the response. I just >>> don't know if there are any consequences to doing that. >>> >>> As an aside, I did try using Google's mod_pagespeed to >>> concatenate-and-minify CSS and JS files, but that went horribly awry -- >>> probably something to do with the dynamic loading of the various parts of >>> the page. >>> >>> Other thoughts? >>> >>> >>> Peter >>> >> > > -- > Peter Murray > Dev/Ops Lead and Project Manager > Cherry Hill Company > > > > _______________________________________________ > Talk mailing list > Talk@lists.collectionspace.org > > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org > >

Thanks, Ray -- I'll start with `master` and go from there. Peter > On May 20, 2016, at 3:02 AM, Ray Lee <rhlee@berkeley.edu <mailto:rhlee@berkeley.edu>> wrote: > > Hi Peter, > Against master for sure, so the fix makes it into the next release. Whether it needs to go into the 4.2 and 4.3 branches is up to Richard and the community. It seems to me that it's a safe change to make to those branches, so I say go for it if you have time. > > Thanks, > Ray > > > On Mon, May 16, 2016 at 8:22 AM, Peter Murray <pmurray@chillco.com <mailto:pmurray@chillco.com>> wrote: > Thanks for the clarification, Ray. I see that Aron created an issue last week (https://issues.collectionspace.org/browse/CSPACE-6952 <https://issues.collectionspace.org/browse/CSPACE-6952> -- thanks, Aron). I might have time to work on this tomorrow or Thursday; I'll have to see how other work proceeds. > > A process question: the fix is likely to be the same for 4.2, 4.3, and HEAD. Should I make three pull requests against the three branches? I've already got a custom branch of 4.2 that I'm working from, so it would only benefit others that are working from the official branches. > > > Peter > >> On May 13, 2016, at 2:33 PM, Ray Lee <rhlee@berkeley.edu <mailto:rhlee@berkeley.edu>> wrote: >> >> It's a bug in code: https://github.com/collectionspace/application/blob/master/tomcat-main/src/main/java/org/collectionspace/chain/controller/TenantServlet.java#L416 <https://github.com/collectionspace/application/blob/master/tomcat-main/src/main/java/org/collectionspace/chain/controller/TenantServlet.java#L416> >> >> I don't think there's a JIRA issue, but I didn't search for one. Could you create one? The bug looks easy to fix, if you want to make a pull request. >> >> Thanks, >> Ray >> >> >> On Fri, May 13, 2016 at 9:16 AM, Peter Murray <pmurray@chillco.com <mailto:pmurray@chillco.com>> wrote: >> Thank you, Jesse -- most helpful. I started with a patch file from the GitHub commit: >> >> https://github.com/OaklandMuseum/ui/commit/3d186e4f07efa6b46feed5a59174bd7e8a634c96.patch <https://github.com/OaklandMuseum/ui/commit/3d186e4f07efa6b46feed5a59174bd7e8a634c96.patch> >> >> Then I edited it to replace some of the tenant-specific file names in the WRO -- I have not made nearly the same number of customizations there than are in OMCA. I also replaced the tenant name where it was specified in the patch. I applied the patch to the source directory with `patch -p 1` and cleaned up a few instances where patch couldn't automatically modify the source code. Then I ran `mvn -Pminimize,tomcat clean install` on the source directory and tried it out. So far the tests on my vagrant machine are much improved. I'll try it on the production server over the weekend. >> >> Ray: I couldn't tell if your observation that the 'app layer continues to look for "text/javascript" to apply the cache control header' meant that this was a bug in the code or a change in the configuration. Jira ticket? >> >> >> Peter >> >> >>> On May 12, 2016, at 12:53 PM, Jesse Martinez <mjesse@gmail.com <mailto:mjesse@gmail.com>> wrote: >>> >>> Hi Peter, >>> >>> To answer your second question: There's a poorly documented way to use a built-in tool for minimizing the UI js & css assets found on this wiki page: https://wiki.collectionspace.org/pages/viewpage.action?pageId=77824080 <https://wiki.collectionspace.org/pages/viewpage.action?pageId=77824080> >>> >>> The default UI web resource optimization (wro) file is outdated so you will need to make a few changes to it and the ui pom.xml and src/build.xml files. I have a recent commit that documents my tenant-specific changes to get the minimization build script to work. >>> >>> https://github.com/OaklandMuseum/ui/commit/3d186e4f07efa6b46feed5a59174bd7e8a634c96 <https://github.com/OaklandMuseum/ui/commit/3d186e4f07efa6b46feed5a59174bd7e8a634c96> >>> >>> FYI, The build tool will complain about syntax in a few files -- a trailing comma after the last element in an array/object. >>> >>> Jesse >>> >>> >>> >>> On Thu, May 12, 2016 at 12:09 PM, Peter Murray <pmurray@chillco.com <mailto:pmurray@chillco.com>> wrote: >>> I'm looking at the performance of the UI in the web browser, and I noticed that the HTML, CSS and PNG files are cached, but the browser is going to back to the server for JavaScript files. A typical CSS request returns these headers: >>> >>> Cache-Control:max-age=2592000 >>> Connection:Keep-Alive >>> Content-Encoding:gzip >>> Content-Length:14512 >>> Content-Type:text/css;charset=UTF-8 >>> Date:Thu, 12 May 2016 16:03:23 GMT >>> Keep-Alive:timeout=5, max=99 >>> Server:Apache-Coyote/1.1 >>> Strict-Transport-Security:max-age=15768000 >>> Vary:Accept-Encoding >>> >>> While a JavaScript request returns these headers >>> >>> Connection:Keep-Alive >>> Content-Encoding:gzip >>> Content-Type:application/javascript;charset=UTF-8 >>> Date:Thu, 12 May 2016 15:59:17 GMT >>> Keep-Alive:timeout=5, max=97 >>> Server:Apache-Coyote/1.1 >>> Strict-Transport-Security:max-age=15768000 >>> Transfer-Encoding:chunked >>> Vary:Accept-Encoding >>> >>> Note the lack of a Cache-Control header in the JavaScript file. I have Apache as a proxy in front of the Tomcat instance (to handle the initial redirect to the tenant login URL and to do the SSL processing), so I think I can force Apache to add a Cache-Control header to the response. I just don't know if there are any consequences to doing that. >>> >>> As an aside, I did try using Google's mod_pagespeed to concatenate-and-minify CSS and JS files, but that went horribly awry -- probably something to do with the dynamic loading of the various parts of the page. >>> >>> Other thoughts? >>> >>> >>> Peter -- Peter Murray Dev/Ops Lead and Project Manager Cherry Hill Company