Live data from Hacker News

Nginx: a caching, thumbnailing, reverse proxying image server

charlesleifer.com

11–20 of 59 posts

Re: Nginx: a caching, thumbnailing, reverse proxying image server

#11
post #10

I found the nginx native image library completely inadequate a few years ago, so I had to use the perl module to connect it to imagemagick libraries instead. Much higher quality results. Not sure if they have improved the native library but I doubt it has the flexibility. The important part is caching the results because of the expensive cpu time. ps. googling about the current state of this came up with an interesti…

Agreed

Re: Nginx: a caching, thumbnailing, reverse proxying image server

#12
post #9

Does the image_filter module use the GPU? Image filtering is an expensive operation for the CPU, with large latencies as well.

Actually GPU latencies and transfer costs dominate most simple image filtering operations. A GPU might be fast once the data is in GPU local RAM, but if just transferring the data back and forth takes 3x the time running the filter locally, what's the point?

You're better off performing it on a CPU, of course SIMD optimized.

Besides, web servers probably won't have GPUs anyways.

Re: Nginx: a caching, thumbnailing, reverse proxying image server

#13
post #12
post #9

Does the image_filter module use the GPU? Image filtering is an expensive operation for the CPU, with large latencies as well.

Actually GPU latencies and transfer costs dominate most simple image filtering operations. A GPU might be fast once the data is in GPU local RAM, but if just transferring the data back and forth takes 3x the time running the filter locally, what's the point? You're better off performing it on a CPU, of course SIMD optimized. Besides, web servers probably won't have GPUs anyways.

Intel is building entire Xeon lines with embedded GPUs for serving web imagery.

And these Intel Xeon's with embedded GPUs don't need to transfer data to the coprocessor, since they operate off of system memory, so transfer latencies are a non-issue.

Re: Nginx: a caching, thumbnailing, reverse proxying image server

#14
post #7

I was wondering if an additional cookie based security token is possible with secure_link module. (show image only if session cookie is present) Apparently, it is possible, great! One of the google results: https://gist.github.com/hilbix/5921589

Secure_link module shouldn't be used for anything security related. I think it uses plain md5 and without even an hmac.

Re: Nginx: a caching, thumbnailing, reverse proxying image server

#15
post #4

I wish the author had gone into more detail about why they chose to stop using Varnish.

I stopped using varnish because, after all, my site is just a blog and Nginx is just fine for my needs. It has a single backend server, so there's no load-balancing. Basically, I was already using Nginx to serve static files, and my caching logic was so simple it was actually easier to move it into Nginx.

Re: Nginx: a caching, thumbnailing, reverse proxying image server

#16
post #4

I wish the author had gone into more detail about why they chose to stop using Varnish.

I stopped using varnish because, after all, my site is just a blog and Nginx is just fine for my needs. It has a single backend server, so there's no load-balancing. Basically, I was already using Nginx to serve static files, and my caching logic was so simple it was actually easier to move it into Nginx.

Perhaps better a better question is why you were using Varnish in the first place?

I'm genuinely curious because I've never stood up Varnish before so maybe there's an anti-pattern / gotcha to learn from.

Re: Nginx: a caching, thumbnailing, reverse proxying image server

#17

This is a cool little project showcasing some of NginX's lesser known modules in action. However, I have one nitpick. The caching server's main location is a bit of a cargo-cult unoptimization. They have specified: location ^/(.+)$ { When the equivalent: location / { Is shorter, clearer, and does not incur a regular expression capture on every request that is never used.

The difference is that the last one also matches requests to "/", while the regex ensures that there is at least a single character after the "/".

That allows "/" to be used for other purposes, e.g. redirecting to the main page of the site, or displaying a nice error page. (However, in this case it simply shows the default Debian Nginx installation page: http://m.charlesleifer.com/ )

Re: Nginx: a caching, thumbnailing, reverse proxying image server

#18

This is a cool little project showcasing some of NginX's lesser known modules in action. However, I have one nitpick. The caching server's main location is a bit of a cargo-cult unoptimization. They have specified: location ^/(.+)$ { When the equivalent: location / { Is shorter, clearer, and does not incur a regular expression capture on every request that is never used.

I (I'm not the author) shamefully do some cargo cult Nginx because I don't understand how the location matching really works.

My ideal web server would have a configuration that resembles a decision procedure in a programming language, so I can have a mental model for what makes it choose one route over the others, and how settings are combined, etc.

Somehow Nginx repeatedly makes me and my coworkers very confused—are we crazy or just mildly incompetent? Should I read an Nginx book?

(One time I wanted to do something fairly straightforward, I think using a conditional inside some block, and when I looked in the manual it warned very strongly that this might cause segmentation faults. I was like WTF?)

Re: Nginx: a caching, thumbnailing, reverse proxying image server

#19
His setup is vulnerable to hash length extension attacks:

  secure_link_md5 "my awesome secret $uri";
This means anyone can extend the URI (eg. adding "/../../../some/other/file" at the end of the filename) and compute a valid key, and force the server to access an arbitrary image file on the backend. If the backend is a private server not publicly accessible, then this may be a security issue.

This is why in the ngx_http_secure_link_module's documentation the secret is appended (instead of prepended), see http://nginx.org/en/docs/http/ngx_http_secure_link_module.ht...:

  secure_link_md5 "$secure_link_expires$uri$remote_addr secret";
The Nginx doc is also at fault because it fails to explain why it is important to append the secret and not prepend it. I just emailed security-alert@nginx.org to let them know.
Post reply on HN