On 6 May 2014 16:11, Indo Php wrote:
> Hi
>
> When doing resizing on the image, I got the error below
> gd-png: fatal libpng error: IDAT: CRC error
>
>
I'm pretty sure this means that your PNG image file is damaged (the CRC
isn't correct). Try opening and resaving your PNG in an image editor to
On 6 May 2014 16:39, Makailol Charls wrote:
> Is it necessary to have an extension to image file to set proper
> content-type for Nginx? Couldn't web server set the content-type from *file
> type* ?
>
That would require Nginx to inspect the file contents and make a guess as
to what file type it
> 1. It is not recommended to use the rewrite_by_lua directive directly
You can do the same with access_by_lua
> Finally, ensure your version of ngx_lua, ngx_memc, and the nginx core are
recent enough.
They are recent.
Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,249754,249921#msg-
On 8 May 2014 06:05, rodrigo.aiello wrote:
> Nginx is receiving the bytes and then
> delivering. I wonder if anyone has gone through this problem and found a
> better solution.
Indeed, Nginx reads the whole response from the backend before a single
byte is sent to the client. That can add laten
I realize that this is an old topic, but I bumped into this issue as well
and submitted a patch, which introduces an additional option to control
whether hidden files are shown or not by the autoindex module.
http://trac.nginx.org/nginx/ticket/557
Best Regards,
Shin
Posted at Nginx Forum:
http:
Hello!
On Tue, May 6, 2014 at 11:30 PM, kay wrote:
> Sure, you can use nginx.conf from my previous message and this server
> config:
>
I've noticed 2 obvious mistakes in your config. See blow.
> server {
> listen 80;
>
> rewrite_by_lua '
> local res = ngx.location.capture("/memc?cmd=ge
Aha good to know! I'm not responsible for this backend, so I'll harass my
colleague about it :) Thanks.
Thijs
On Wed, May 7, 2014 at 5:34 PM, Jonathan Matthews
wrote:
> On 7 May 2014 15:51, Thijs Koerselman wrote:
> > I have a backend returning a last modified header in CEST.
>
> RF2616 says "
Ruslan, you're a hero!
I just commented the following line in my existing config
#proxy_cache_bypass $dontcache;
and everything works now!
I won't be able to comprehend such nginx's behaviour w/o your help, greatly
appreciated.
Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,249880,249
Hi,
I'm nginx newbie. I'm reading src/core/ngx_slab.c, and am confused
as to
the purpose of NGX_SLAB_PAGE_START.
As far as I can understand, when allocating a block, the most
significant
bit (MSB) of first page's corresponding ngx_slab_page_s::slab is set "1".
as we can see from :
Hi Mark,
> Looks like it's hit Ubuntu now. Since I've updated, I've not seen a
> single one of these errors, which is great. I was seeing at least a
> handful per hour before, so that's a pretty good sign.
Confirmed: USN-2192-1 [1] provides the fix for CVE-2010-5298.
Regards,
Lukas
[1]
On 04.05.2014 16:52, Markus Weippert wrote:
> I'm having some strange issues using nginx 1.6 with ECC certs.
> Handshakes fail for clients using TLSv1.2 and SNI but only if the
> requested server block is not the default_server.
Had a further look into that. The problem seems to occur if nginx is
On Wed, Apr 30, 2014 at 12:55 AM, Lukas Tribus wrote:
> Hi,
>
>
> >> The fix is already in OpenBSD [4], Debian and Ubuntu will probably ship
> the
> >> patch soon, also see [5] and [6].
> >
> > Oh, cool, that's good news that it's upstream then. Getting the patch
> > to apply is a piece of cake.
Jonathan Matthews Wrote:
---
> On 7 May 2014 19:05, rodrigo.aiello wrote:
> > requests are taking too long to process
> [snip]
> > 1 EC2 Micro (Nginx)
>
> I found your problem. Micro instances are a false economy. Stop using
> them.
>
> ___
On 7 May 2014 19:05, rodrigo.aiello wrote:
> requests are taking too long to process
[snip]
> 1 EC2 Micro (Nginx)
I found your problem. Micro instances are a false economy. Stop using them.
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.or
I have a service in my java application that I get the id of an image,
height and width. I do image resizing according to the provided dimensions
and return the bytes. As I am using a nginx in front of application
server(tomcat), requests are taking too long to process because nginx is on
a differe
On 7 May 2014 15:51, Thijs Koerselman wrote:
> I have a backend returning a last modified header in CEST.
RF2616 says "All HTTP date/time stamps MUST be represented in
Greenwich Mean Time (GMT), without exception".
I'm not very surprised nginx isn't doing what you expect. Fix your backend.
> Wh
I'm using version 1.5.12 btw.
On Wed, May 7, 2014 at 4:51 PM, Thijs Koerselman
wrote:
> I have a backend returning a last modified header in CEST.
>
> I'm using a 1sec proxy that revalidates as described here:
> http://whitequark.org/blog/2014/04/05/page-caching-with-nginx/
>
> My problem is tha
I have a backend returning a last modified header in CEST.
I'm using a 1sec proxy that revalidates as described here:
http://whitequark.org/blog/2014/04/05/page-caching-with-nginx/
My problem is that when nginx makes the request to the backend it changes
CEST into GMT, without adjusting the time.
On Wed, May 07, 2014 at 08:53:56AM -0400, Kirill K. wrote:
> Thanks, Ruslan,
> Thing is, I tried to "debug" whether $dontcache is being set at all by
> exposing it via response headers (along with content-length), and it shows
> that $upstream_response_length is ignored by map completely, i.e. no m
>
> I request all Nginx master/experts to help me.
>
That looks like an odd way to *ask* for help.
If you wanna *request* help, consider getting paid support. But even doing
that, that is rude...
What the error says is that the '*backend* closed connection
prematurely'... You should look into i
On Tue, May 6, 2014 at 8:39 PM, dcaillibaud wrote:
> > > 2) (I guess E but I'm not so sure), this can also be a pitfall
> > example (how
> > > complicating things can lead to unexpected behaviour)
> > >
> > > location /images/ {
> > > location ~* \.(gif|jpg|jpeg)$ {
> > > [ configuratio
Thanks, Ruslan,
Thing is, I tried to "debug" whether $dontcache is being set at all by
exposing it via response headers (along with content-length), and it shows
that $upstream_response_length is ignored by map completely, i.e. no matter
where I use $dontcache, it will never get any value different
On Wed, May 07, 2014 at 01:38:04AM -0400, Kirill K. wrote:
> Hello,
> I'm trying to avoid caching of small responses from upstreams using map:
> map $upstream_http_content_length $dontcache {
> default 0;
> ~^\d\d$ 1;
> ~^\d$ 1;
> }
>
> Unfortunatelly, nginx seems to ignore $upstream* variables at
Has anyone started looking at nginx with userspace TCP. Is there any
opensource TCP stack available which can work well with Nginx.
Sandstorm seems to be working in user space and claiming to handle more CPS
than Nginx.
Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,249893,249893#msg-
Probably that's the case, and I'm not sure if there's a way to use map
inside upstream {...} or other context apart from http {...}, which makes
your theory sound correct.
What confuses me most: I googled a bit, and using map w/
$upstream_response_length is the most common way offered to avoid cach
On 7 May 2014 06:38, Kirill K. wrote:
> Hello,
> I'm trying to avoid caching of small responses from upstreams using map:
> map $upstream_http_content_length $dontcache {
> default 0;
> ~^\d\d$ 1;
> ~^\d$ 1;
> }
>
> Unfortunatelly, nginx seems to ignore $upstream* variables at the map
> processing
Hi Sergey,
I just checked the repository again and there is indeed a debuginfo package
available now for the latest build (1.6). This really helps.
Thanks a lot,
Dominik
Posted at Nginx Forum:
http://forum.nginx.org/read.php?2,248527,249884#msg-249884
_
27 matches
Mail list logo
