Forwarded to devs "Serve static files directly by nginx" option available also when nginx set to "native" mode

[Sergio Manzi]

TITLE:

"Serve static files directly by nginx" option available also when nginx set to "native" mode​

PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE:

Plesk 17.8.10 (upgraded from 17.5.3#40)
CentOS 7.4.1708, Kernel 3.10.0-693​

PROBLEM DESCRIPTION:

When one sets nginx to work in "native" (non-proxy) mode, the "Smart static files processing" option is correctly greyed out.

Wouldn't be the case that the "Serve static files directly by nginx" option be grayed out too? Aren't all static files directly served by nginx in this case?​

STEPS TO REPRODUCE:

In whatever subscription turn off "Proxy mode"​

ACTUAL RESULT:

"Smart static files processing" is grayed out
"Serve static files directly by nginx" is not greyed out​

EXPECTED RESULT:

Both options being grayed out​

ANY ADDITIONAL INFORMATION:

​

YOUR EXPECTATIONS FROM PLESK SERVICE TEAM:

Answer the question​

 

[IgorG]

If I correctly understand the point of the question, the answer is here: Apache and Nginx Settings

 

[Sergio Manzi]

ahemm... if I understand you correctly, no, that's not what I meant: let me try to express my self in clearer terms.

• In Plesk, web sites are served either by Apache_proxied_by_Nginx or by Nginx_itself_no_Apache_involved_ever (btw, we don't have the Apache_only_no_nginx_involved option, unless maybe if we don't have installed nginx at all, which is something I haven't tried yet).
  
  
• If you chose the Nginx_itself_no_Apache_involved_ever solution, then, by definition, everything (static or not static) is served by Nginx

At this point the option labelled "Serve static files directly by nginx" and which actually means "Restrict serving of static files by nginx to the following file types" doesn't makes any sense at all and should be made unavailable.

IMHO that options page and the accompanying documentation sorely needs a review based on the "Principle of least astonishment" and DWIM principle:

• The "Proxy mode" checkbox should be changed to a switch (two reciprocally exclusive radio buttons) labelled "Use nginx as an Apache proxy" and "Use nginx only/natively"). Think how many people have unchecked that box expecting to have their files directly served by Apache... astonishment! (and yes, I know that now there is a little explanation below making the thing less astonishing...)
  
  
• The "Smart static files processing" checkbox should be labelled "Serve static files directly by nginx" and available only (as it is now) when nginx is set to "proxy mode".
  
  
• The checkbox now labelled "Serve static files directly by nginx" should be labelled "Restrict serving static files by nginx to this file types" and it too made available only when nginx is set to "proxy mode" <--- This is the main point of this "report"

Also the documentation has something... curious. Read some paragraph below in the article you pointed me to:

To serve all static content via nginx:

1. Go to Websites & Domains > Apache & nginx Settings and scroll down to the "nginx settings" section.
2. Select the Proxy mode and Smart static files processing checkboxes.
3. Make sure that the Serve static files directly by nginx checkbox is not selected.
4. Click OK.

So, "To serve all static content via nginx" one must switch off... guess what? "Serve static files directly by nginx"!!! Sorry, but... W. T. F.!

 

[MarkM]

Removing NGINX throws Apache back onto Port 80.

Just my two cents.

 

[Sergio Manzi]

Removing NGINX throws Apache back onto Port 80.

Thanks Mark! And I hope that all nginx related options are unavailable at that point, right?

 

[MarkM]

If you go under a domain, you still see an option called "Apache & nginx Settings", clicking it you have verbiage that says "If Apache is running with nginx as a frontend server, you can specify the nginx settings on this page as well." - However, no actual options.... that i've seen.

 

[Ruslan Kosolapov]

Hi.



When nginx is in proxy mode (and "Smart files" is turned on), Apache determines which files are static, which files are dynamic.
When nginx is in non-proxy mode, the value of that option specifies which files are static.

Regarding the rest:

1. I agree the UI/UX is not the best one, it is a point of a future improvements.
2. I don't agree the documentation is bad. It can be improved (anything can be improved), but it already contains the right description how it works.

The "Smart static files processing" checkbox should be labelled "Serve static files directly by nginx"
The checkbox now labelled "Serve static files directly by nginx" should be labelled "Restrict serving static files by nginx to this file types"

Looks like you've been lost in the meaning of the options. The captions that you suggested completely contradict with the current functionality.

There is a very rough scheme how it works (I hope correctly draw it):

 

[Sergio Manzi]

Hello Ruslan!

I really appreciate you taking the time to explain all the fine details.

Everything it is now clear and I also checked that indeed what happens (with the expires...) is exactly what you described.

Fantastic, but... I'm astonished!

But first of all let me say that there has been a misunderstanding about the docs: I never intended to criticize the docs which indeed perfectly explains all that there is to explain. The problem was about them (the docs) having to (correctly) make a construction that reads "To serve all static content via nginx ... Make sure that the Serve static files directly by nginx checkbox is not selected". Don't you perceive that as mind twisting? Astonishing I would say... But again I'm not putting the blame on the docs at all!

Now that I finally understood the functionality and the "double duty" of the "Serve static files directly by nginx" option as also an "Apply expires only to this file types" option when in in nginx-only mode, I must say that there is a further astonishment of finding the "Expires" option functioning under nginx: as it is listed in the "Common Apache Settings" section I always thought it applied to Apache only and it being inoperative under nginx. Do also all other options in that (Apache) section apply to the nginx-only scenario?

Really, I think that all the wording/organization (mind you, not the functionality, which is great!) of that configuration page should be reviewed. I'm ready to bet that support calls will decrease in a significant way...

Your scheme is great and it should be made a sticky!

Thanks again,

Sergio

 

[Ruslan Kosolapov]

Hi Sergio.

You're right that the configuration page should be reviewed.

About the docs - got it, your points are clear for me. I'll talk with techdocs, will see what we can do.

 

[Sergio Manzi]

Thanks again, Ruslan, I appreciate your acknowledgment, really!

If in the future you think I might be of any help (detailing what I find confusing and/or suggesting different organization/wording of that page), please don't hesitate to get in touch with me.

Regards,

Sergio