Christoph Rabel 7年 前 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. :-) 投票するためにはログインが必要です。 次として送信する: キャンセル David H Nebinger Christoph Rabel 7年 前 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. 投票するためにはログインが必要です。 次として送信する: キャンセル Christoph Rabel David H Nebinger 7年 前 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. 投票するためにはログインが必要です。 次として送信する: キャンセル David H Nebinger Christoph Rabel 7年 前 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" 投票するためにはログインが必要です。 次として送信する: キャンセル Christoph Rabel David H Nebinger 7年 前 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. 投票するためにはログインが必要です。 次として送信する: キャンセル David H Nebinger Christoph Rabel 7年 前 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. 投票するためにはログインが必要です。 次として送信する: キャンセル Christoph Rabel David H Nebinger 7年 前 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. 投票するためにはログインが必要です。 次として送信する: キャンセル David H Nebinger Christoph Rabel 7年 前 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. 投票するためにはログインが必要です。 次として送信する: キャンセル
David H Nebinger Christoph Rabel 7年 前 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. 投票するためにはログインが必要です。 次として送信する: キャンセル Christoph Rabel David H Nebinger 7年 前 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. 投票するためにはログインが必要です。 次として送信する: キャンセル David H Nebinger Christoph Rabel 7年 前 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" 投票するためにはログインが必要です。 次として送信する: キャンセル Christoph Rabel David H Nebinger 7年 前 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. 投票するためにはログインが必要です。 次として送信する: キャンセル David H Nebinger Christoph Rabel 7年 前 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. 投票するためにはログインが必要です。 次として送信する: キャンセル Christoph Rabel David H Nebinger 7年 前 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. 投票するためにはログインが必要です。 次として送信する: キャンセル David H Nebinger Christoph Rabel 7年 前 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. 投票するためにはログインが必要です。 次として送信する: キャンセル
Christoph Rabel David H Nebinger 7年 前 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. 投票するためにはログインが必要です。 次として送信する: キャンセル David H Nebinger Christoph Rabel 7年 前 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" 投票するためにはログインが必要です。 次として送信する: キャンセル Christoph Rabel David H Nebinger 7年 前 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. 投票するためにはログインが必要です。 次として送信する: キャンセル David H Nebinger Christoph Rabel 7年 前 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. 投票するためにはログインが必要です。 次として送信する: キャンセル Christoph Rabel David H Nebinger 7年 前 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. 投票するためにはログインが必要です。 次として送信する: キャンセル David H Nebinger Christoph Rabel 7年 前 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. 投票するためにはログインが必要です。 次として送信する: キャンセル
David H Nebinger Christoph Rabel 7年 前 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" 投票するためにはログインが必要です。 次として送信する: キャンセル Christoph Rabel David H Nebinger 7年 前 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. 投票するためにはログインが必要です。 次として送信する: キャンセル David H Nebinger Christoph Rabel 7年 前 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. 投票するためにはログインが必要です。 次として送信する: キャンセル Christoph Rabel David H Nebinger 7年 前 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. 投票するためにはログインが必要です。 次として送信する: キャンセル David H Nebinger Christoph Rabel 7年 前 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. 投票するためにはログインが必要です。 次として送信する: キャンセル
Christoph Rabel David H Nebinger 7年 前 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. 投票するためにはログインが必要です。 次として送信する: キャンセル David H Nebinger Christoph Rabel 7年 前 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. 投票するためにはログインが必要です。 次として送信する: キャンセル Christoph Rabel David H Nebinger 7年 前 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. 投票するためにはログインが必要です。 次として送信する: キャンセル David H Nebinger Christoph Rabel 7年 前 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. 投票するためにはログインが必要です。 次として送信する: キャンセル
David H Nebinger Christoph Rabel 7年 前 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. 投票するためにはログインが必要です。 次として送信する: キャンセル Christoph Rabel David H Nebinger 7年 前 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. 投票するためにはログインが必要です。 次として送信する: キャンセル David H Nebinger Christoph Rabel 7年 前 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. 投票するためにはログインが必要です。 次として送信する: キャンセル
Christoph Rabel David H Nebinger 7年 前 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. 投票するためにはログインが必要です。 次として送信する: キャンセル David H Nebinger Christoph Rabel 7年 前 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. 投票するためにはログインが必要です。 次として送信する: キャンセル
David H Nebinger Christoph Rabel 7年 前 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. 投票するためにはログインが必要です。 次として送信する: キャンセル
Patricia Hevia 6年 前 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!. 投票するためにはログインが必要です。 次として送信する: キャンセル
Orin Fink 6年 前 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. 投票するためにはログインが必要です。 次として送信する: キャンセル David H Nebinger Orin Fink 6年 前 - 編集済み 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! 投票するためにはログインが必要です。 次として送信する: キャンセル Orin Fink David H Nebinger 6年 前 Ok, yeah that would make sense then since we are using Apache inbetween. Thanks for the comment and again for the post! 投票するためにはログインが必要です。 次として送信する: キャンセル
David H Nebinger Orin Fink 6年 前 - 編集済み 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! 投票するためにはログインが必要です。 次として送信する: キャンセル Orin Fink David H Nebinger 6年 前 Ok, yeah that would make sense then since we are using Apache inbetween. Thanks for the comment and again for the post! 投票するためにはログインが必要です。 次として送信する: キャンセル
Orin Fink David H Nebinger 6年 前 Ok, yeah that would make sense then since we are using Apache inbetween. Thanks for the comment and again for the post! 投票するためにはログインが必要です。 次として送信する: キャンセル
(あなた) 6年 前 [...] 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 投票するためにはログインが必要です。 次として送信する: キャンセル
Mauro Mariuzzo 5年 前 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 投票するためにはログインが必要です。 次として送信する: キャンセル
Luis J. Gomez 5年 前 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. 投票するためにはログインが必要です。 次として送信する: キャンセル David H Nebinger Luis J. Gomez 5年 前 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. 投票するためにはログインが必要です。 次として送信する: キャンセル David H Nebinger Luis J. Gomez 5年 前 The scripts should be available now, Luis. 投票するためにはログインが必要です。 次として送信する: キャンセル
David H Nebinger Luis J. Gomez 5年 前 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. 投票するためにはログインが必要です。 次として送信する: キャンセル
David H Nebinger Luis J. Gomez 5年 前 The scripts should be available now, Luis. 投票するためにはログインが必要です。 次として送信する: キャンセル