Slashdot Mirror

To make the HTTP resource secure on a HTTPS page we can link to the resource and provide a hash of the asset or file in the HTML. HTML already supports this.

Mozilla calls it "Subresource Integrity"

NGIX has supported their own version of secure_link since back when we thought MD5 was secure:
http://nginx.org/en/docs/http/ngx_http_secure_link_module.html

This is how you make mixed content HTTPS cache friendly without giving all your security to Cloudflare or similar.

Fuck off Goolag.

Next problem please.

The HTTPS negotiation was slower than HTTP, but the actual encryption took valuable server compute resources

True, TLS increases CPU overhead for a site that just serves static documents. But web applications have also become more dynamic since the late 1990s when SSL (now called TLS) was invented. With more server-side processing for each page view, the fraction of server CPU time devoted to actually sending the resource to the PC has diminished. I grant that the cost is greater than zero, but the benefit is also greater than zero.

There are solutions today, but none are free

I thought NGINX as the frontend reverse proxy in front of your application server was free software under the 2-clause BSD license.

To this day, for example, Go has no support for run-time loading of other Go-code (no dlopen()!)

What's this?

Implementing something like Apache in Go would be a non-starter

It happens to be written in C, but nginx has done enormously well.

running multiple Go-apps on the same computer wastes RAM (the most valuable resource in a computer) since the kernel is unaware of the duplications and can not allow multiple processes to share pages of physical RAM used by them

I take it you're unaware of kernel same-page merging. As a caveat, people should be aware of potential side-channel security implications of any memory conservation/deduplication approach, and shared libraries are not immune from some of these implications, either. -PCP

Please show a link to the Tomecat init script you are talking about, because I was unable to found a ready to use init script in the Tomecat source code repository. I confess that did't spend a long time searching it, but since you seem to known well Tomecat (unlike me) you should find it quickly.

Unfortunately the initscripts are mostly distribution specific and lack a good standardization. See the nginx example to illustrate the problem: http://wiki.nginx.org/InitScri...

The systemd infrastructure provides features that don't exists initscripts, so yes there have a bit more coupling than initscripts, but since the features list is not the same, the comparison is biased . If you have a better architecture to propose to provides the same set of features, please show your talent.

*) Feature: now nginx can be build with BoringSSL and LibreSSL. Thanks to Piotr Sikora.

I know this is off topic but...

> When RH (which is, both in business model and revenue, a small player in the IT panorama)

I continue to hear this and see absolutely no evidence of it. I see evidence to the contrary, in the US, India and Europe, over the last 20 years.
Generally, it's RPM/RH that is first listed. It's not alphabetical. This isn't because they are lucky. The simple explanation is that RH is the most frequently used and therefore put at the top as a simple matter of UI layout (most common choices go to the top of a list, within reason).

Let's just pull some random packages out of the web -

RH nearest top:
http://www.aerospike.com/downl...
http://dev.nuodb.com/download-...
http://wiki.nginx.org/Install
http://cassandra.apache.org/do... (rpm mentioned before deb)

Debian nearest top:
http://dev.mysql.com/downloads...

This is a fun game, pick me a list that shows more Debian love!
I would like to keep a pulse on things but I just don't see this assertion (that RH is the marginal market) bearing out as anything but wishful thinking.

Microsoft's never let anybody dump a bunch of memory from my server.

While this may be true, consider Code Red (2001 worm). Setting aside for a moment that it attacked an exploit Microsoft had patched a month prior, the mere existence of an IIS overflow bug, allowing the installing of a worm, meant the attacker could have gained access not only to all the input and output on the server, but also to all the data sitting on the server. Patches servers were safe, but that's assuming the flaw was not being exploited before it was patched.

It's of course not just Microsoft. Back on the open source side, my own favorite web server software, Nginx, had patches for buffer overflows. You're going to find this in both proprietary and open source software until static code analysis tools get good enough to catch all the buffer overflows, and programmers are using these tools as part of their standard programming process.

Heartbleed's bad, but by no means is it necessarily worse that what can be done with a buffer overflow, except that Heartbleed leaves no commonly visible trail (unusual files on the hard drive, or process running in memory).

In the world of Open Source, I would also like to see the sum total of Open Source web servers VS. IIS:

Nginx http://www.nginx.org/ ( really popular and at least this is in one of the graphs)
Lighttpd http://www.lighttpd.net/ (personally, I have found many reasons use this one in the past and I'm sure I will again)
Cherokee http://www.cherokee-project.co... (yet to explore past a basic setup)
Roxen Webserver http://www.roxen.com/products/... (Still need to take for a spin)

And then special purpose web servers.

HTTP Explorer http://http-explorer.sourcefor...
HFS HTTP File Server http://www.rejetto.com/hfs/

At least that's all I can think of. Anybody else?
I know some of these take up negligible market share, but I would still like to see their market share lumped together.

In case some people don't know, nginx uses http1 to connect to the servers, which means a new connection for reach request.

HTTP/1.1 proxying is currently available in the development version so if needed you can use that.

http://wiki.nginx.org/NginxJavaServers

I swear that Nginx has been a bit of a success. Thankfully it was looked over completely. http://wiki.nginx.org/Main

Many of us have moved away from Apache altogether. I mean, with lighttpd and nginx available, there's really little need for Apache these days.

Sounds like they need to use a web server that can easily handle such a load, even if they're junk requests. What is that web server? Why, it's nginx of course!

Either it is a joke, or it was ages ago.

Nginx has a completely decent documentation: http://wiki.nginx.org/Main

And some tutorials to begin with: http://nginx.org/en/docs/http/request_processing.html - http://nginx.org/en/docs/http/server_names.html - http://nginx.org/en/docs/http/configuring_https_servers.html

Either it is a joke, or it was ages ago.

Nginx has a completely decent documentation: http://wiki.nginx.org/Main

And some tutorials to begin with: http://nginx.org/en/docs/http/request_processing.html - http://nginx.org/en/docs/http/server_names.html - http://nginx.org/en/docs/http/configuring_https_servers.html

Either it is a joke, or it was ages ago.

Nginx has a completely decent documentation: http://wiki.nginx.org/Main

And some tutorials to begin with: http://nginx.org/en/docs/http/request_processing.html - http://nginx.org/en/docs/http/server_names.html - http://nginx.org/en/docs/http/configuring_https_servers.html

Either it is a joke, or it was ages ago.

Nginx has a completely decent documentation: http://wiki.nginx.org/Main

And some tutorials to begin with: http://nginx.org/en/docs/http/request_processing.html - http://nginx.org/en/docs/http/server_names.html - http://nginx.org/en/docs/http/configuring_https_servers.html

I participated in an interesting Ubuntu forum discussion about a data corruption in the ext4 file system and Canonical's decision to deploy the OS despite some misgivings of some of its engineers. I gave a link where bug chasers trying to build the final release suggested that they install ext3 as default since there were some unresolved bugs allegedly in ext4 when transferring large files. One engineer took over responsibility of the bug and said it was not conclusive enough to change their plans.

It was very obvious that the priority was sticking to the schedule and the published feature set at all costs. You can find the post here: http://forum.nginx.org/read.php?26,18172
The reference cited contains the entire text from which the excerpt was taken. I think it gives a clear example of why these problems persist. Canonical won't be accused of vaporware like Microsoft is when it is late delivering RTM versions. What it is being accused of is far worse I think and may have a long term cost. Especially if this is not a one time thing.

Nginx. Seriously.