Maintenance talk

[h5bp]

Maintenance talk

[LeoColomb]

There are literally thousands of pages of HTTP-related RFCs.
Depending on the site frameworks, there are thousands of more pages discussing best practices. Best practices for security. Best practices for mobile. Best practices for widest browser compatibility. ... some of these best practices make tradeoffs, and some conflict with other recommendations, depending on what you prioritize for your site.

Not so many any more @gstrauss! 😁
The ones applicable for server configuration have been quite consolidated in the past years, plus browser ecosystem stabilized significantly.
Best practice now are more focused on compliance than edge case support, especially when mobile and security cases are now targeting compliance as well.

There is no one-size-fits-all.

That being said, as you mentioned, a configuration can't cover 100% of worldwide needs.
Thought, some parts can be pushed for default.
Are you ok to review them?

• Exec privileges
  What is the default? Is there a warning if started with root?

• Document root
  This is definitely a local configuration stuff. (right?)

• Server header
  What is the default? Is it possible to opt-in for version in header?
  In the ideal world, the header is empty in prod and with version in debug sessions.

• Modules
  Not sure anything is applicable for default values.

• Log path
  What is the default? Is it possible to follow these standards regarding log filenames and location?

• Deflate file types
  Ideal world would to have a solid default template when enabled, but I'm not sure if it is feasible.

• Index filenames
  What is the default? Is it possible to get index.html prio 1?

• MIME-types
  This is the part where default can be amazing.
  MIME types are not that critical for browsers, but change the quality of a server if aligned on it.

• Access deny
  Not sure anything is applicable for default values.

• Cache control/Expire
  This is a bit tricker.
  Like deflate, ideal world would to have a solid default template when enabled, but I'm not sure if it is feasible.

[gstrauss]

• Exec privileges
  What is the default? Is there a warning if started with root?

lighttpd is an executable and runs as the user/group which starts the executable, unless lighttpd is run as root and lighttpd.conf specifies a different user/group under which to run. This is typical best practice for daemons which are capable of starting as root and dropping privileges to less-privileged accounts. For one use case on embedded systems where lighttpd may be used to configured the system, lighttpd runs as root to be able to configure the system. There are other ways to do it with setuid executables or privileged backend services which accept requests from lighttpd, but running lighttpd as root is simple and is prevalent.

The h5bp template config specifes an arbitrary user/group under which to run so that if lighttpd is started as root, lighttpd drops privileges. This is a reasonable example use:

# Run as an unprivileged user
server.username = "www"
server.groupname = "www"

• Document root
  This is definitely a local configuration stuff. (right?)

lighttpd requires that server.document-root be specified to a location from which static files are served. Similar to server.username and server.groupname, whose accounts must exist on the target system, the target of server.document-root should exist as a directory on the system running lighttpd.

• Server header
  What is the default? Is it possible to opt-in for version in header?

The default is lighttpd and lighttpd version. lighttpd allows "" to be specified to omit the header. Some other web servers do not allow Server to be omitted. For some large metrics collection sites which rank usage of web servers, lighttpd is lower on the list in part due to lighttpd allowing omission of Server response header and other web servers not allowing such omission. Specifying server.tag = "lighttpd" limits the response header to Server: lighttpd

• Modules
  Not sure anything is applicable for default values.

I am following the practices suggested on https://wiki.lighttpd.net/ (a large part which has been written by me).
lighttpd.conf server.modules should list the modules used by the rest of the configuration.

• Log path
  What is the default? Is it possible to follow these standards regarding log filenames and location?

The default is no access log unless configured.
The default is no error log unless configured. Error trace goes to STDERR if server.errorlog and server.errorlog-use-syslog are not configured/enabled.

• Deflate file types
  Ideal world would to have a solid default template when enabled, but I'm not sure if it is feasible.

My PR attempts to follow the configs of other h5bp web server configs.
Sometimes such configs can be site-specific. Case in point, the caching headers in h5bp web server configs which make .html files uncachable is a very specific setting and not one that I use or recommend. I almost always set Cache-Control max-age on .html files, even if also restricting it to private caching.

• Index filenames
  What is the default? Is it possible to get index.html prio 1?

If not specified, the feature is disabled.
index-file.names tries the files in the order listed, so index.html is tried first when listed first.

• MIME-types
  This is the part where default can be amazing.
  MIME types are not that critical for browsers, but change the quality of a server if aligned on it.

And your feedback is ???
My PR attempts to follow the configs of other h5bp web server configs.
lighttpd also ships with a script which can read /etc/mime.types and generate mimetype.assign from /etc/mime.types.

• Access deny
  Not sure anything is applicable for default values.

Files ending in ~ is a typical convention for temporary files, e.g. from file editors.
Configuring lighttpd to avoid serving editor temporary files is a good practice.
.inc files hail from the time where server-side include files were more popular, and that extension is sometimes used by other scripting frameworks, so, again, a good practice. Feel free to suggest other temporary file extensions to add to the list.

• Cache control/Expire
  This is a bit tricker.
  Like deflate, ideal world would to have a solid default template when enabled, but I'm not sure if it is feasible.

My PR attempts to follow the configs of other h5bp web server configs. As I said above, I personally disagree with some of the settings. However, providing caching settings as a template may be better than providing none.

The shortest valid lighttpd.conf is one line:
server.document-root = "/path/to/document/root"
That uses lighttpd defaults to listen on 0.0.0.0:80 and serve static files. However, that is not much of a template for modern best practices, which is why this PR provides examples of some -- but far from all -- lighttpd features.

[LeoColomb]

My point were not really a request for documentation, but more to challenge the default values of the server to see if the config in this repo is relevant or not. 😬 So this is not a review of your PR either, but a trial to see what is relevant to configure in general
But thanks for your complete reply anyway! 😊

• Exec privileges
• Document root

Ok

• Server header

You are right about the server name.
Is it possible to disable the version per default?

• Modules

Ok

• Log path

Great for STDERR 👍
Is it possible to enable the access logs without specifying the path? Does it use STDOUT per default?

• Index filenames

So what is the default behavior when accessing a directory with setting unset?

• MIME-types

Well, my feedback is to understand if lighttpd follow these standard MIME-types per default or not really.
Great if it can read a mime.types, is there a default and up-to-date one shipped with lighttpd?

• Access deny

I do agree that avoiding serving editor temporary files is a good practice. So are these files blocked per default without any config?

---

However, that is not much of a template for modern best practices, which is why this PR provides examples of some

Again, the discussion on this issue is not related to the PR, but trying to understand if it's possible to make these best practices you are mentioning the default behavior of lighttpd without configuration (or the most minimal as possible).
My ideal world would be the one where we can archive this repo by saying “hey, lighttpd brings the perfect setting values per default, this boilerplate is pointless”.
I hope you see my point! 😊

[gstrauss]

I am not sure that I can reply politely to that, so I'll try to reply briefly instead:

I hope you see my point!

I do. I think that if you are not going to RTFM, then you have no credibility in providing default configs for anything. I hope that you will delete lighttpd configs and all web server configs since the ones you have do not follow the (non-existent) "magic" to do everything exactly the way that you want it, and without any configuration.

lighttpd does not do magic. lighttpd tries to have secure, logical defaults, where logical describes practical logic of those with practical knowledge of how things work, not dreamer wishlists of "do what I mean". lighttpd behavior is documented in the lighttpd documentation: https://wiki.lighttpd.net/

I already described lighttpd's server.tag behavior. Your continued question about defaults suggests you have not understood what I wrote and you have not looked at the lighttpd documentation because you are asking for something different.

lighttpd default behavior with the simplest one-line config server.document-root = "..." is to listen on 0.0.0.0:80 and to serve static files from the specified server.document-root location. If a file does not exist, a 404 Not Found is returned. If a url-path ends in '/' and does not exist, then a 403 Forbidden is returned. If you have mod_indexfile enabled and the index file exists, that is returned. If not that, then if mod_dirlisting is enabled, then a directory listing is generated. With the simplest one-line config, neither are enabled and the behavior is 403 Forbidden.

[gstrauss]

There is no one-size-fits-all config.

Example:

• Do you want directory listings? Then enable mod_dirlisting, or handle with index.php, or ...
• Do you not want directory listings? Then do not do any of the above.

There is no one-size-fits-all config.

[gstrauss]

My point were not really a request for documentation, but more to challenge the default values of the server to see if the config in this repo is relevant or not.

I submitted a PR #4 two weeks ago. This was briefly discussed in h5bp/server-configs#179 and then you started this "discussion", which so far is merely a more detailed repetition of what was already said in h5bp/server-configs#179

Since @LeoColomb is not well-versed in lighttpd and seems unwilling to take the time to read the documentation, I request that someone else review #4.

[gstrauss]

@roblarsen From the questions asked by @LeoColomb above, it is apparent that @LeoColomb has not recently referenced the lighttpd documentation. That's fine and is @LeoColomb's prerogative.

Is there some other h5bp member who might be more qualified to review #4?

If h5bp does have the expertise, that is great. If not, or if there is not desire or availability of time to maintain the configurations recommended for use with the web servers, then I kindly ask that the web server configurations be removed. Thank you.

[LeoColomb]

I'm sorry if I wrote anything wrong @gstrauss.
I do believe this is simply a mutual misunderstanding of our respective goal around here, as it all starts.

I'm afraid to be the last volunteer in H5BP org willing to follow both server software configuration changes and web standards evolution (or at least I try, most probably not perfect about it), and the only alone maintainer of these repos…

In any case, indeed as it seems politeness is not part of the discussion anymore, I suggest we don't go further, which is fine.