Possible bug in SSI include handling

Hello all,

This file structure required to duplicate this bug is a bit complex to
explain. Therefore, I put the required files into a tiny archive,
which you can download from [1].

This problem is appearing in latest 0.7 and 0.8 releases on FreeBSD
7.2. Download the archive, extract it to some directory, and start
nginx with the included configuration file (edit the “root” directive
as needed first). If you then view /good1.html and /good2.html, you
should see the following text:

File Header
Page Header
Content
Sidebar
Page Footer
File Footer

Viewing bad.html will show this:

File Header
Page Header
Content
Sidebar

The last two lines are missing. If you look at the source for all
three files, you’ll see where the problem is. Conceptually, they are
all identical, but something breaks when executing the SSI code in
bad.html. More precisely, execution seems to stop after the first
include directive in content_footer.inc. Files good1.html and
good2.html show two ways of fixing the problem, but I cannot find a
good explanation as to why the original file doesn’t work as expected.

I started looking through the source code for ssi module, but I’m
hoping that someone more familiar with nginx internals would be able
to find a solution quicker. It seems that adding wait=“yes” to the
virtual include in bad.html also fixes the problem, so I suspect that
the issue is with requests being performed in parallel.

  • Max

[1] http://www.bhsai.org/downloads/ssi.tgz

Hello!

On Wed, Dec 30, 2009 at 02:42:16PM -0500, Maxim K. wrote:

This file structure required to duplicate this bug is a bit complex to
explain. Therefore, I put the required files into a tiny archive,
which you can download from [1].

[…]

I started looking through the source code for ssi module, but I’m
hoping that someone more familiar with nginx internals would be able
to find a solution quicker. It seems that adding wait=“yes” to the
virtual include in bad.html also fixes the problem, so I suspect that
the issue is with requests being performed in parallel.

I’m able to reproduce it here, thanks. I’ll take a look (but most
likely after New Year).

It seems to be caused by mix of waited (include file=… is
implicitly waited) and non-waited subrequests with non-trivial
nesting.

BTW, Happy New Year!

Maxim D.

This bug has existed for a long time since nginx 0.6×. Sockets are
closed
incorrectly when ssi sub-requests finished.

The workaround is to set ‘wait’ attribute to be true which make
sub-requests
go to back end one by one.

Hello!

On Thu, Dec 31, 2009 at 05:58:40PM +0300, Maxim D. wrote:

I started looking through the source code for ssi module, but I’m
hoping that someone more familiar with nginx internals would be able
to find a solution quicker. It seems that adding wait=“yes” to the
virtual include in bad.html also fixes the problem, so I suspect that
the issue is with requests being performed in parallel.

I’m able to reproduce it here, thanks. I’ll take a look (but most
likely after New Year).

Patch.

Maxim D.

On Sat, Jan 2, 2010 at 11:15 PM, Maxim D. [email protected]
wrote:

which you can download from [1].
likely after New Year).

Patch.

Maxim D.

Tested with nginx 0.8.31 and 0.7.64. Works great, thanks!

  • Max

Thanks for this patch. Can you tell me what the r->buffered exactly
means?
Thank you.

On Sat, Jan 2, 2010 at 8:15 PM, Maxim D. [email protected] wrote:

which you can download from [1].
likely after New Year).

Patch.

Has this been integrated into nginx yet?


Joe Van D.
http://fixieconsulting.com

Hello!

On Tue, Jan 19, 2010 at 12:51:23PM -0800, Joe Van D. wrote:

explain. Therefore, I put the required files into a tiny archive,
I’m able to reproduce it here, thanks. šI’ll take a look (but most
likely after New Year).

Patch.

Has this been integrated into nginx yet?

Not yet.

Maxim D.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs