Christoph Rabel 7 Years Ago Do you know by chance if it is perfectly safe to cache the whole theme? (Of course, theme deployments necessitate clearing the cache, no big deal)It bugs me somewhat that Liferay appends a lot of stuff to various urls, e.g. the browserId:aui.css?browserId=firefox&themeId=...Currently I am just ignoring those parameters and caching theme css, js, ... unconditionally. I remember, I did a quick look into the code once and came to the conclusion that it is safe. Especially with 7.0+, since the theme is build now with gulp. But I might have missed something.I usually use nginx because I know it quite well and it has the advantage that it can handle ssl. With the Varnish solution I would still need to use an nginx causing an extra hop. And I don't need the flexibility of Varnish, nginx is a quite powerful reverse proxy and cache server too. Of course, in case you have tested it and Varnish beats nginx, I am all ears. :-) Please sign in to reply. Reply as... Cancel David H Nebinger Christoph Rabel 7 Years Ago Well, the theme includes the FM templates and those, of course, are dynamic and are used during page construction in the portal; it's one of the reasons that I had to treat friendly URLs as uncacheable, because of the content generated into the pages depending upon whether you are logged in or not (and what roles you might have).The extra parms are sometimes important. For example, if you have to code up something to work against different browser types, the browser id allows you to manage that. The theme id is, of course, the selected theme to use for the page, and the others have their own purposes. Ignoring these args is only safe if you know that you're not needing to have anything dynamic based on their values.Choosing nginx is fine; I think it depends most upon a) which you might have more experience and/or documentation to support and b) which might offer you necessary flexibility in controlling caching.For example, if I know that I'm using current user role to customize generated javascript, I know I can put in an appropriate rule for Varnish to skip caching that particular asset yet still cache the rest. Nginx might have the same available features, I'm just not that familiar with it.If you are, I'd encourage you to write a blog post about how to front Liferay/Tomcat w/ Nginx as that may prove to be useful to the community. Please sign in to reply. Reply as... Cancel Christoph Rabel David H Nebinger 7 Years Ago I think you misunderstood me. I was talking about the files delivered by the paths /my-theme /LR 6.2) or /o/my-theme (LR 7). Those files seem to be static. The template files are never send from there, so it doesn't matter what they contain.I usually add a rule to nginx to cache the whole path unconditionally. Never hat any problems with it.As I said, I looked in the sourcecode, LR does some search & replace in the files but I deemed it harmless/cacheable. But still, it would be nice to have a confirmation. In my opinion, those browser parameters are legacy. But a second opinion would be nice.I tried to cache pages too, but I couldn't do it because in most environments I can't tell if a user is authenticated. I would need something like the userId in a cookie or header to cache per user.Btw.: Removing the cache directive on /documents is pretty dangerous. You allow proxies to cache the file. So, a company proxy might cache supersecretfile.doc and deliver it to anybody who requests it. Might be fine in your case, but in general you must not do that.I usually cache only certain public folder paths and add them to the configuration one by one.Nginx vs. Varnish: Well, Varnish is more powerful/flexible since it was developed to be a cache server. But Nginx is more than sufficient for most usecases. It's better than Apache IMHO, Apache is powerful too, but very, very difficult to configure. I guess, your usecase would be doable in Nginx, it's not to difficult to configure stuff on a "per path" basis.About blogging: I will think about it, but usually things like blogging (and alas, forum) end up on the "when I have some spare time ..." stack. Please sign in to reply. Reply as... Cancel David H Nebinger Christoph Rabel 7 Years Ago Well, I can't tell you (or anyone) it is okay to cache based on theme path. It really does depend upon whether you have browser-specific stuff in your theme. Your theme might not have browser-specific stuff in it and therefore it may be okay to ignore the browser id, but the next five folks reading the blog and comments might have theme developers who have made such changes.That's why I have the bullet item, "Adding Varnish requires you to know your portal." You can't just guess at whether to cache or not, you have to know.Allowing caching on /documents can be dangerous, and my commented VCL form points out the issue. Liferay determines permissions based upon who a user is and whether they have view rights or not. I added an override to cache images regardless of what Liferay specified, thus potentially ignoring Liferay security. Why? Well when you look at the urls that come in not only do they have /documents/.../my-image.jpg, but the path continues with /<a big UUID value>/... So basically I'm allowing "security by obscurity". Is this something everyone should do on their portal? Well, this is also a case of needing to know your portal; you have to balance the ability to cache images with the possible security exposure that might come with it.Note I was only overriding caching for /documents/ that had image/* mime types, so it was not set up to be a blanket cache override for all of your Docs And Media. That definitely is not going to be a good idea, unless of course you "know your portal" and have basically a public-only facing site with documents that are never "supersecretfile.doc" Please sign in to reply. Reply as... Cancel Christoph Rabel David H Nebinger 7 Years Ago Um, I still don't get it. How would I add browser specific stuff to my theme and do something e.g. with the browserId? All resources css, js, ... are delivered by Liferay, not by "me". Of course, I could write something like a servlet filter, but I that's not part of the theme for me. Do I miss something here?Not sure what you mean with the uuid part of the url. You can simply remove the uuid from the url and it will still work (well, most of the time, there are some special cases like moving the file to a different folder).Anyway, I really like to cache the documents folder, it's great to deliver images from the webserver. They really excel there. I just wanted to emphasize that one has to be really careful with caching or manipulating cache headers. You have to make sure that you only cache "public" content. Please sign in to reply. Reply as... Cancel David H Nebinger Christoph Rabel 7 Years Ago I haven't traced through all of the code to see how it works, but if you check out AggregateFilter you can see that they are doing some magic to CSS when the browser is not IE. There may be other cases where CS and/or JS are allowing for built-in modification by the core.UUID can be stripped, but like I said, I'm relying on security by obscurity and didn't say this was a good fit for everyone. I think there can be valid cases where you may want to allow caching of images rather than forcing the portal to do security checks every time.And I wholeheartedly agree w/ only caching public content, especially if you have sensitive images or docs to protect. Anytime you override Liferay's cache control headers, you really need to understand the ramifications and make sure it's an optimization that works for your particular portal implementation.Caching the whole docs folder though caries risk that other readers should take note of; Liferay does the permission checks on whether something from Docs & Media is accessible, and if you let the web server/Varnish cache and return on it's own, you're bypassing the permission checks. Sometimes this can be okay, sometimes not so much.You must know your portal to know what will work for you. Please sign in to reply. Reply as... Cancel Christoph Rabel David H Nebinger 7 Years Ago Mmmh, yes, I know. As far as I can tell, AggregateFilter removes just one style in gulp themes. I don't remember details for LR 6.2, but I we deemed it safe to ignore cache the theme files unconditionally. Well, at least for our themes.IMHO this whole browserId stuff is legacy and unnecessary with gulp. Add an autoprefixer and be done with it. Please sign in to reply. Reply as... Cancel David H Nebinger Christoph Rabel 7 Years Ago If you're doing a clean theme rewrite, this might be an option. But if you're dealing with a theme upgrade (or a skills upgrade for your team), you might need to keep relying upon the browser id handling. Please sign in to reply. Reply as... Cancel
David H Nebinger Christoph Rabel 7 Years Ago Well, the theme includes the FM templates and those, of course, are dynamic and are used during page construction in the portal; it's one of the reasons that I had to treat friendly URLs as uncacheable, because of the content generated into the pages depending upon whether you are logged in or not (and what roles you might have).The extra parms are sometimes important. For example, if you have to code up something to work against different browser types, the browser id allows you to manage that. The theme id is, of course, the selected theme to use for the page, and the others have their own purposes. Ignoring these args is only safe if you know that you're not needing to have anything dynamic based on their values.Choosing nginx is fine; I think it depends most upon a) which you might have more experience and/or documentation to support and b) which might offer you necessary flexibility in controlling caching.For example, if I know that I'm using current user role to customize generated javascript, I know I can put in an appropriate rule for Varnish to skip caching that particular asset yet still cache the rest. Nginx might have the same available features, I'm just not that familiar with it.If you are, I'd encourage you to write a blog post about how to front Liferay/Tomcat w/ Nginx as that may prove to be useful to the community. Please sign in to reply. Reply as... Cancel Christoph Rabel David H Nebinger 7 Years Ago I think you misunderstood me. I was talking about the files delivered by the paths /my-theme /LR 6.2) or /o/my-theme (LR 7). Those files seem to be static. The template files are never send from there, so it doesn't matter what they contain.I usually add a rule to nginx to cache the whole path unconditionally. Never hat any problems with it.As I said, I looked in the sourcecode, LR does some search & replace in the files but I deemed it harmless/cacheable. But still, it would be nice to have a confirmation. In my opinion, those browser parameters are legacy. But a second opinion would be nice.I tried to cache pages too, but I couldn't do it because in most environments I can't tell if a user is authenticated. I would need something like the userId in a cookie or header to cache per user.Btw.: Removing the cache directive on /documents is pretty dangerous. You allow proxies to cache the file. So, a company proxy might cache supersecretfile.doc and deliver it to anybody who requests it. Might be fine in your case, but in general you must not do that.I usually cache only certain public folder paths and add them to the configuration one by one.Nginx vs. Varnish: Well, Varnish is more powerful/flexible since it was developed to be a cache server. But Nginx is more than sufficient for most usecases. It's better than Apache IMHO, Apache is powerful too, but very, very difficult to configure. I guess, your usecase would be doable in Nginx, it's not to difficult to configure stuff on a "per path" basis.About blogging: I will think about it, but usually things like blogging (and alas, forum) end up on the "when I have some spare time ..." stack. Please sign in to reply. Reply as... Cancel David H Nebinger Christoph Rabel 7 Years Ago Well, I can't tell you (or anyone) it is okay to cache based on theme path. It really does depend upon whether you have browser-specific stuff in your theme. Your theme might not have browser-specific stuff in it and therefore it may be okay to ignore the browser id, but the next five folks reading the blog and comments might have theme developers who have made such changes.That's why I have the bullet item, "Adding Varnish requires you to know your portal." You can't just guess at whether to cache or not, you have to know.Allowing caching on /documents can be dangerous, and my commented VCL form points out the issue. Liferay determines permissions based upon who a user is and whether they have view rights or not. I added an override to cache images regardless of what Liferay specified, thus potentially ignoring Liferay security. Why? Well when you look at the urls that come in not only do they have /documents/.../my-image.jpg, but the path continues with /<a big UUID value>/... So basically I'm allowing "security by obscurity". Is this something everyone should do on their portal? Well, this is also a case of needing to know your portal; you have to balance the ability to cache images with the possible security exposure that might come with it.Note I was only overriding caching for /documents/ that had image/* mime types, so it was not set up to be a blanket cache override for all of your Docs And Media. That definitely is not going to be a good idea, unless of course you "know your portal" and have basically a public-only facing site with documents that are never "supersecretfile.doc" Please sign in to reply. Reply as... Cancel Christoph Rabel David H Nebinger 7 Years Ago Um, I still don't get it. How would I add browser specific stuff to my theme and do something e.g. with the browserId? All resources css, js, ... are delivered by Liferay, not by "me". Of course, I could write something like a servlet filter, but I that's not part of the theme for me. Do I miss something here?Not sure what you mean with the uuid part of the url. You can simply remove the uuid from the url and it will still work (well, most of the time, there are some special cases like moving the file to a different folder).Anyway, I really like to cache the documents folder, it's great to deliver images from the webserver. They really excel there. I just wanted to emphasize that one has to be really careful with caching or manipulating cache headers. You have to make sure that you only cache "public" content. Please sign in to reply. Reply as... Cancel David H Nebinger Christoph Rabel 7 Years Ago I haven't traced through all of the code to see how it works, but if you check out AggregateFilter you can see that they are doing some magic to CSS when the browser is not IE. There may be other cases where CS and/or JS are allowing for built-in modification by the core.UUID can be stripped, but like I said, I'm relying on security by obscurity and didn't say this was a good fit for everyone. I think there can be valid cases where you may want to allow caching of images rather than forcing the portal to do security checks every time.And I wholeheartedly agree w/ only caching public content, especially if you have sensitive images or docs to protect. Anytime you override Liferay's cache control headers, you really need to understand the ramifications and make sure it's an optimization that works for your particular portal implementation.Caching the whole docs folder though caries risk that other readers should take note of; Liferay does the permission checks on whether something from Docs & Media is accessible, and if you let the web server/Varnish cache and return on it's own, you're bypassing the permission checks. Sometimes this can be okay, sometimes not so much.You must know your portal to know what will work for you. Please sign in to reply. Reply as... Cancel Christoph Rabel David H Nebinger 7 Years Ago Mmmh, yes, I know. As far as I can tell, AggregateFilter removes just one style in gulp themes. I don't remember details for LR 6.2, but I we deemed it safe to ignore cache the theme files unconditionally. Well, at least for our themes.IMHO this whole browserId stuff is legacy and unnecessary with gulp. Add an autoprefixer and be done with it. Please sign in to reply. Reply as... Cancel David H Nebinger Christoph Rabel 7 Years Ago If you're doing a clean theme rewrite, this might be an option. But if you're dealing with a theme upgrade (or a skills upgrade for your team), you might need to keep relying upon the browser id handling. Please sign in to reply. Reply as... Cancel
Christoph Rabel David H Nebinger 7 Years Ago I think you misunderstood me. I was talking about the files delivered by the paths /my-theme /LR 6.2) or /o/my-theme (LR 7). Those files seem to be static. The template files are never send from there, so it doesn't matter what they contain.I usually add a rule to nginx to cache the whole path unconditionally. Never hat any problems with it.As I said, I looked in the sourcecode, LR does some search & replace in the files but I deemed it harmless/cacheable. But still, it would be nice to have a confirmation. In my opinion, those browser parameters are legacy. But a second opinion would be nice.I tried to cache pages too, but I couldn't do it because in most environments I can't tell if a user is authenticated. I would need something like the userId in a cookie or header to cache per user.Btw.: Removing the cache directive on /documents is pretty dangerous. You allow proxies to cache the file. So, a company proxy might cache supersecretfile.doc and deliver it to anybody who requests it. Might be fine in your case, but in general you must not do that.I usually cache only certain public folder paths and add them to the configuration one by one.Nginx vs. Varnish: Well, Varnish is more powerful/flexible since it was developed to be a cache server. But Nginx is more than sufficient for most usecases. It's better than Apache IMHO, Apache is powerful too, but very, very difficult to configure. I guess, your usecase would be doable in Nginx, it's not to difficult to configure stuff on a "per path" basis.About blogging: I will think about it, but usually things like blogging (and alas, forum) end up on the "when I have some spare time ..." stack. Please sign in to reply. Reply as... Cancel David H Nebinger Christoph Rabel 7 Years Ago Well, I can't tell you (or anyone) it is okay to cache based on theme path. It really does depend upon whether you have browser-specific stuff in your theme. Your theme might not have browser-specific stuff in it and therefore it may be okay to ignore the browser id, but the next five folks reading the blog and comments might have theme developers who have made such changes.That's why I have the bullet item, "Adding Varnish requires you to know your portal." You can't just guess at whether to cache or not, you have to know.Allowing caching on /documents can be dangerous, and my commented VCL form points out the issue. Liferay determines permissions based upon who a user is and whether they have view rights or not. I added an override to cache images regardless of what Liferay specified, thus potentially ignoring Liferay security. Why? Well when you look at the urls that come in not only do they have /documents/.../my-image.jpg, but the path continues with /<a big UUID value>/... So basically I'm allowing "security by obscurity". Is this something everyone should do on their portal? Well, this is also a case of needing to know your portal; you have to balance the ability to cache images with the possible security exposure that might come with it.Note I was only overriding caching for /documents/ that had image/* mime types, so it was not set up to be a blanket cache override for all of your Docs And Media. That definitely is not going to be a good idea, unless of course you "know your portal" and have basically a public-only facing site with documents that are never "supersecretfile.doc" Please sign in to reply. Reply as... Cancel Christoph Rabel David H Nebinger 7 Years Ago Um, I still don't get it. How would I add browser specific stuff to my theme and do something e.g. with the browserId? All resources css, js, ... are delivered by Liferay, not by "me". Of course, I could write something like a servlet filter, but I that's not part of the theme for me. Do I miss something here?Not sure what you mean with the uuid part of the url. You can simply remove the uuid from the url and it will still work (well, most of the time, there are some special cases like moving the file to a different folder).Anyway, I really like to cache the documents folder, it's great to deliver images from the webserver. They really excel there. I just wanted to emphasize that one has to be really careful with caching or manipulating cache headers. You have to make sure that you only cache "public" content. Please sign in to reply. Reply as... Cancel David H Nebinger Christoph Rabel 7 Years Ago I haven't traced through all of the code to see how it works, but if you check out AggregateFilter you can see that they are doing some magic to CSS when the browser is not IE. There may be other cases where CS and/or JS are allowing for built-in modification by the core.UUID can be stripped, but like I said, I'm relying on security by obscurity and didn't say this was a good fit for everyone. I think there can be valid cases where you may want to allow caching of images rather than forcing the portal to do security checks every time.And I wholeheartedly agree w/ only caching public content, especially if you have sensitive images or docs to protect. Anytime you override Liferay's cache control headers, you really need to understand the ramifications and make sure it's an optimization that works for your particular portal implementation.Caching the whole docs folder though caries risk that other readers should take note of; Liferay does the permission checks on whether something from Docs & Media is accessible, and if you let the web server/Varnish cache and return on it's own, you're bypassing the permission checks. Sometimes this can be okay, sometimes not so much.You must know your portal to know what will work for you. Please sign in to reply. Reply as... Cancel Christoph Rabel David H Nebinger 7 Years Ago Mmmh, yes, I know. As far as I can tell, AggregateFilter removes just one style in gulp themes. I don't remember details for LR 6.2, but I we deemed it safe to ignore cache the theme files unconditionally. Well, at least for our themes.IMHO this whole browserId stuff is legacy and unnecessary with gulp. Add an autoprefixer and be done with it. Please sign in to reply. Reply as... Cancel David H Nebinger Christoph Rabel 7 Years Ago If you're doing a clean theme rewrite, this might be an option. But if you're dealing with a theme upgrade (or a skills upgrade for your team), you might need to keep relying upon the browser id handling. Please sign in to reply. Reply as... Cancel
David H Nebinger Christoph Rabel 7 Years Ago Well, I can't tell you (or anyone) it is okay to cache based on theme path. It really does depend upon whether you have browser-specific stuff in your theme. Your theme might not have browser-specific stuff in it and therefore it may be okay to ignore the browser id, but the next five folks reading the blog and comments might have theme developers who have made such changes.That's why I have the bullet item, "Adding Varnish requires you to know your portal." You can't just guess at whether to cache or not, you have to know.Allowing caching on /documents can be dangerous, and my commented VCL form points out the issue. Liferay determines permissions based upon who a user is and whether they have view rights or not. I added an override to cache images regardless of what Liferay specified, thus potentially ignoring Liferay security. Why? Well when you look at the urls that come in not only do they have /documents/.../my-image.jpg, but the path continues with /<a big UUID value>/... So basically I'm allowing "security by obscurity". Is this something everyone should do on their portal? Well, this is also a case of needing to know your portal; you have to balance the ability to cache images with the possible security exposure that might come with it.Note I was only overriding caching for /documents/ that had image/* mime types, so it was not set up to be a blanket cache override for all of your Docs And Media. That definitely is not going to be a good idea, unless of course you "know your portal" and have basically a public-only facing site with documents that are never "supersecretfile.doc" Please sign in to reply. Reply as... Cancel Christoph Rabel David H Nebinger 7 Years Ago Um, I still don't get it. How would I add browser specific stuff to my theme and do something e.g. with the browserId? All resources css, js, ... are delivered by Liferay, not by "me". Of course, I could write something like a servlet filter, but I that's not part of the theme for me. Do I miss something here?Not sure what you mean with the uuid part of the url. You can simply remove the uuid from the url and it will still work (well, most of the time, there are some special cases like moving the file to a different folder).Anyway, I really like to cache the documents folder, it's great to deliver images from the webserver. They really excel there. I just wanted to emphasize that one has to be really careful with caching or manipulating cache headers. You have to make sure that you only cache "public" content. Please sign in to reply. Reply as... Cancel David H Nebinger Christoph Rabel 7 Years Ago I haven't traced through all of the code to see how it works, but if you check out AggregateFilter you can see that they are doing some magic to CSS when the browser is not IE. There may be other cases where CS and/or JS are allowing for built-in modification by the core.UUID can be stripped, but like I said, I'm relying on security by obscurity and didn't say this was a good fit for everyone. I think there can be valid cases where you may want to allow caching of images rather than forcing the portal to do security checks every time.And I wholeheartedly agree w/ only caching public content, especially if you have sensitive images or docs to protect. Anytime you override Liferay's cache control headers, you really need to understand the ramifications and make sure it's an optimization that works for your particular portal implementation.Caching the whole docs folder though caries risk that other readers should take note of; Liferay does the permission checks on whether something from Docs & Media is accessible, and if you let the web server/Varnish cache and return on it's own, you're bypassing the permission checks. Sometimes this can be okay, sometimes not so much.You must know your portal to know what will work for you. Please sign in to reply. Reply as... Cancel Christoph Rabel David H Nebinger 7 Years Ago Mmmh, yes, I know. As far as I can tell, AggregateFilter removes just one style in gulp themes. I don't remember details for LR 6.2, but I we deemed it safe to ignore cache the theme files unconditionally. Well, at least for our themes.IMHO this whole browserId stuff is legacy and unnecessary with gulp. Add an autoprefixer and be done with it. Please sign in to reply. Reply as... Cancel David H Nebinger Christoph Rabel 7 Years Ago If you're doing a clean theme rewrite, this might be an option. But if you're dealing with a theme upgrade (or a skills upgrade for your team), you might need to keep relying upon the browser id handling. Please sign in to reply. Reply as... Cancel
Christoph Rabel David H Nebinger 7 Years Ago Um, I still don't get it. How would I add browser specific stuff to my theme and do something e.g. with the browserId? All resources css, js, ... are delivered by Liferay, not by "me". Of course, I could write something like a servlet filter, but I that's not part of the theme for me. Do I miss something here?Not sure what you mean with the uuid part of the url. You can simply remove the uuid from the url and it will still work (well, most of the time, there are some special cases like moving the file to a different folder).Anyway, I really like to cache the documents folder, it's great to deliver images from the webserver. They really excel there. I just wanted to emphasize that one has to be really careful with caching or manipulating cache headers. You have to make sure that you only cache "public" content. Please sign in to reply. Reply as... Cancel David H Nebinger Christoph Rabel 7 Years Ago I haven't traced through all of the code to see how it works, but if you check out AggregateFilter you can see that they are doing some magic to CSS when the browser is not IE. There may be other cases where CS and/or JS are allowing for built-in modification by the core.UUID can be stripped, but like I said, I'm relying on security by obscurity and didn't say this was a good fit for everyone. I think there can be valid cases where you may want to allow caching of images rather than forcing the portal to do security checks every time.And I wholeheartedly agree w/ only caching public content, especially if you have sensitive images or docs to protect. Anytime you override Liferay's cache control headers, you really need to understand the ramifications and make sure it's an optimization that works for your particular portal implementation.Caching the whole docs folder though caries risk that other readers should take note of; Liferay does the permission checks on whether something from Docs & Media is accessible, and if you let the web server/Varnish cache and return on it's own, you're bypassing the permission checks. Sometimes this can be okay, sometimes not so much.You must know your portal to know what will work for you. Please sign in to reply. Reply as... Cancel Christoph Rabel David H Nebinger 7 Years Ago Mmmh, yes, I know. As far as I can tell, AggregateFilter removes just one style in gulp themes. I don't remember details for LR 6.2, but I we deemed it safe to ignore cache the theme files unconditionally. Well, at least for our themes.IMHO this whole browserId stuff is legacy and unnecessary with gulp. Add an autoprefixer and be done with it. Please sign in to reply. Reply as... Cancel David H Nebinger Christoph Rabel 7 Years Ago If you're doing a clean theme rewrite, this might be an option. But if you're dealing with a theme upgrade (or a skills upgrade for your team), you might need to keep relying upon the browser id handling. Please sign in to reply. Reply as... Cancel
David H Nebinger Christoph Rabel 7 Years Ago I haven't traced through all of the code to see how it works, but if you check out AggregateFilter you can see that they are doing some magic to CSS when the browser is not IE. There may be other cases where CS and/or JS are allowing for built-in modification by the core.UUID can be stripped, but like I said, I'm relying on security by obscurity and didn't say this was a good fit for everyone. I think there can be valid cases where you may want to allow caching of images rather than forcing the portal to do security checks every time.And I wholeheartedly agree w/ only caching public content, especially if you have sensitive images or docs to protect. Anytime you override Liferay's cache control headers, you really need to understand the ramifications and make sure it's an optimization that works for your particular portal implementation.Caching the whole docs folder though caries risk that other readers should take note of; Liferay does the permission checks on whether something from Docs & Media is accessible, and if you let the web server/Varnish cache and return on it's own, you're bypassing the permission checks. Sometimes this can be okay, sometimes not so much.You must know your portal to know what will work for you. Please sign in to reply. Reply as... Cancel Christoph Rabel David H Nebinger 7 Years Ago Mmmh, yes, I know. As far as I can tell, AggregateFilter removes just one style in gulp themes. I don't remember details for LR 6.2, but I we deemed it safe to ignore cache the theme files unconditionally. Well, at least for our themes.IMHO this whole browserId stuff is legacy and unnecessary with gulp. Add an autoprefixer and be done with it. Please sign in to reply. Reply as... Cancel David H Nebinger Christoph Rabel 7 Years Ago If you're doing a clean theme rewrite, this might be an option. But if you're dealing with a theme upgrade (or a skills upgrade for your team), you might need to keep relying upon the browser id handling. Please sign in to reply. Reply as... Cancel
Christoph Rabel David H Nebinger 7 Years Ago Mmmh, yes, I know. As far as I can tell, AggregateFilter removes just one style in gulp themes. I don't remember details for LR 6.2, but I we deemed it safe to ignore cache the theme files unconditionally. Well, at least for our themes.IMHO this whole browserId stuff is legacy and unnecessary with gulp. Add an autoprefixer and be done with it. Please sign in to reply. Reply as... Cancel David H Nebinger Christoph Rabel 7 Years Ago If you're doing a clean theme rewrite, this might be an option. But if you're dealing with a theme upgrade (or a skills upgrade for your team), you might need to keep relying upon the browser id handling. Please sign in to reply. Reply as... Cancel
David H Nebinger Christoph Rabel 7 Years Ago If you're doing a clean theme rewrite, this might be an option. But if you're dealing with a theme upgrade (or a skills upgrade for your team), you might need to keep relying upon the browser id handling. Please sign in to reply. Reply as... Cancel
Patricia Hevia 6 Years Ago Hello David,I'm a rookie using Varnish and I have used your localhost(2).vcl file. I have some problems because the URLs are not cache, the "Age" value is always 0 and the "X-Cache" value is always a MISS.I have debugged and I have found that the code always does a return pass in this code.# liferay friendly urls typically represent dynamic content.# if the url is friendly, let's go straight to fetchif (req.url !~ "\?") { return (pass);}My portal has URLs like these http://localhost/es/web/guest/news or http://localhost/es/web/guest/services. I think that these URLs types should be cache but the file has that code.I do not understand this code, why are not these URLs types (http://localhost/es/web/guest/news) cache?.Thank you very much!. Please sign in to reply. Reply as... Cancel
Orin Fink 6 Years Ago David,Thanks a ton for this post and the reference .vcl file. We've found this to be rather effective in production environments. Although, we did come across an issue that may be worth reviewing for the reference .vcl attached. THere are a few lines that we found to increase the overall header size dramatically when long URLs were in play such as when editors are in the control panel. We removed the following lines.- # Create a header to capture the full URL- set req.http.X-Full-Uri = req.http.host + req.url; - set req.http.X-Full-Url = req.url; and modified line 210...- hash_data(req.http.X-Full-Url);+ hash_data(req.url);It was hard to debug but the users were getting an apache message stating "Bad Request your browser sent a request that this server could not understand" This was happening when the URL string itself was roughly 2600 characters. The lines in this VCL above would then take that url length and add it two more times to the header so now our HTTP header as a whole was going over the default 8K limit that Apache has set for max header length.Thanks again for the work here, please post back if the removal of those lines seems problematic to you in any way. Please sign in to reply. Reply as... Cancel David H Nebinger Orin Fink 6 Years Ago - Edited Thanks, Orin! I haven't hit that problem so far, but maybe I've just been lucky The X-* headers are optional; they are not necessary for the actual request handling. They can be useful if you're doing something on the backend with those original values.I should note that I use Apache <-> Varnish <-> Tomcat, so the Varnish additions to the headers for me don't really affect Apache at all. But I don't claim that my setup is the best, it's just one that has worked for me thus far.As you've found a good working solution, I'd say stick with it! Please sign in to reply. Reply as... Cancel Orin Fink David H Nebinger 6 Years Ago Ok, yeah that would make sense then since we are using Apache inbetween. Thanks for the comment and again for the post! Please sign in to reply. Reply as... Cancel
David H Nebinger Orin Fink 6 Years Ago - Edited Thanks, Orin! I haven't hit that problem so far, but maybe I've just been lucky The X-* headers are optional; they are not necessary for the actual request handling. They can be useful if you're doing something on the backend with those original values.I should note that I use Apache <-> Varnish <-> Tomcat, so the Varnish additions to the headers for me don't really affect Apache at all. But I don't claim that my setup is the best, it's just one that has worked for me thus far.As you've found a good working solution, I'd say stick with it! Please sign in to reply. Reply as... Cancel Orin Fink David H Nebinger 6 Years Ago Ok, yeah that would make sense then since we are using Apache inbetween. Thanks for the comment and again for the post! Please sign in to reply. Reply as... Cancel
Orin Fink David H Nebinger 6 Years Ago Ok, yeah that would make sense then since we are using Apache inbetween. Thanks for the comment and again for the post! Please sign in to reply. Reply as... Cancel
(You) 6 Years Ago [...] Giles Westwood: Large journalarticles like we have are poor performance wise when read from the database, therefore we would like them to always be read from ehcache regardless of which node a user... [...] Read More Please sign in to reply. Reply as... Cancel
Mauro Mariuzzo 5 Years Ago In my experience is not a good choice to put a cache server before Liferay, to process requests going to Liferay. Apart theme resources, that "must" be availables anonymoulsly, all the other URIs could be controlled by liferay permissions and you have to really really know how Liferay works to tune the URIs to cache. I think the right approach is to use a CDN, which Liferay supports ootb. You could setup a Varnish, or a Squid, as an "in-house CDN" and have it serve all the resources Liferay knows could be available anonymously Please sign in to reply. Reply as... Cancel
Luis J. Gomez 5 Years Ago Hi David, first of all, thanks for this blog entry, it contains a lot of usefull information, needed to understand how Varnish works and how it could be configured. Only one thing, I can't find the VCL script mentioned as a reference (localhost-2.vcl on the 05/16/2017 update). Did you remove it from the post? If so, can you please upload it again? Thanks in advance. Please sign in to reply. Reply as... Cancel David H Nebinger Luis J. Gomez 5 Years Ago Hmm, they are connected to the blog still, but I don't see how we can get to them. I'll reach out to the team and see why they are not visible. Please sign in to reply. Reply as... Cancel David H Nebinger Luis J. Gomez 5 Years Ago The scripts should be available now, Luis. Please sign in to reply. Reply as... Cancel
David H Nebinger Luis J. Gomez 5 Years Ago Hmm, they are connected to the blog still, but I don't see how we can get to them. I'll reach out to the team and see why they are not visible. Please sign in to reply. Reply as... Cancel
David H Nebinger Luis J. Gomez 5 Years Ago The scripts should be available now, Luis. Please sign in to reply. Reply as... Cancel