Nginx-1.3.9

Changes with nginx 1.3.9 27 Nov
2012

*) Feature: support for chunked transfer encoding while reading 

client
request body.

*) Feature: the $request_time and $msec variables can now be used 

not
only in the “log_format” directive.

*) Bugfix: cache manager and cache loader processes might not be 

able to
start if more than 512 listen sockets were used.

*) Bugfix: in the ngx_http_dav_module.


Maxim D.

Does the “support for chunked transfer encoding…” mean I don’t need
the extra “chunkin” module to be compiled and linked-in?

Is there a new list of directives I should switch-over to (replacing the
external, chunkin ones)? Maybe there’s a more thorough list of release
notes, I’m just not sure where they are offhand.

Thanks,
AJ

On Tuesday 27 November 2012 19:35:34 AJ Weber wrote:

Does the “support for chunked transfer encoding…” mean I don’t need
the extra “chunkin” module to be compiled and linked-in?

Yes.

Is there a new list of directives I should switch-over to (replacing the
external, chunkin ones)? Maybe there’s a more thorough list of release
notes, I’m just not sure where they are offhand.

There are no special directives at all. It just works.

wbr, Valentin V. Bartenev

http://nginx.org/en/donation.html

On 2012-11-27 15:26, Maxim D. wrote:

Changes with nginx 1.3.9 27
Nov 2012
[…]

Thanks :slight_smile: Will there be an updated version of the SPDY patch as well?
It looks like patch.spdy-53.txt just needs minor adjustments in
src/http/ngx_http.h and src/http/ngx_http_request_body.c (at least it
applies, compiles and runs in my case after doing so) but I am unsure if
there is anything else behind the scenes which might break it sooner or
later.

Cheers
-cs

"There are no special directives at all. It just works. "

Those are the best updates! :wink:
Thank you!

Unexpectedly compiling fresh 1.3.9 with nginx_upload_module I’ve met

objs -I src/http -I src/http/modules -I src/mail
-o objs/addon/nginx_upload_module-2.2.0/
ngx_http_upload_module.o
…/nginx_upload_module-2.2.0/ngx_http_upload_module.c
…/nginx_upload_module-2.2.0/ngx_http_upload_module.c: In function
ngx_http_read_upload_client_request_body:
…/nginx_upload_module-2.2.0/ngx_http_upload_module.c:2628: error:
ngx_http_request_body_t has no member named to_write
…/nginx_upload_module-2.2.0/ngx_http_upload_module.c:2687: error:
ngx_http_request_body_t has no member named to_write
…/nginx_upload_module-2.2.0/ngx_http_upload_module.c: In function
ngx_http_do_read_upload_client_request_body:
…/nginx_upload_module-2.2.0/ngx_http_upload_module.c:2769: error:
ngx_http_request_body_t has no member named to_write
…/nginx_upload_module-2.2.0/ngx_http_upload_module.c:2785: error:
ngx_http_request_body_t has no member named to_write
…/nginx_upload_module-2.2.0/ngx_http_upload_module.c:2877: error:
ngx_http_request_body_t has no member named to_write
make[1]: *** [objs/addon/nginx_upload_module-2.2.0/
ngx_http_upload_module.o] Error 1
make[1]: Leaving directory `/root/nginx-1.3.9’
make: *** [build] Error 2

any ideas?

Pawe Marzec

Wiadomo napisana w dniu 2012-11-27, o godz. 15:26, przez Maxim D.:

On Wednesday 28 November 2012 00:32:12 Christoph Schug wrote:

there is anything else behind the scenes which might break it sooner or
later.

Don’t worry, it’s indeed minor adjustments while applying.
It should work as well as with the previous nginx version.

wbr, Valentin V. Bartenev

http://nginx.org/en/donation.html

Hi all

After I replaced the 3rd party h.264 streaming module with the native
one.I found that there was no sound when playing some of MP4 files with
MP3 audio codec. Is there anyway to pseudo-streaming MP4 files with
H.264/MP3 codec by using the native mp4 module.Or any plan to support
this type of MP4 files in the future ?

Thank you.

Sheng

On Nov 28, 2012, at 8:54 , Sheng.Zheng wrote:

Hi all

After I replaced the 3rd party h.264 streaming module with the native one.I
found that there was no sound when playing some of MP4 files with MP3 audio codec.
Is there anyway to pseudo-streaming MP4 files with H.264/MP3 codec by using the
native mp4 module.Or any plan to support this type of MP4 files in the future ?

Could you try nginx version 1.3.5 or newer ?

Changes with nginx 1.3.5 21 Aug
2012

*) Change: the ngx_http_mp4_module module no longer skips tracks in
   formats other than H.264 and AAC.


Igor S.

Thanks Igor,I can pseudo-streaming H.264/MP3 files after update from
1.2.5 to 1.3.9.
Do you plan to back port this change to 1.2.x stable version or i have
to wait for the 1.4.x.

Sheng

On Nov 28, 2012, at 11:51 , Sheng.Zheng wrote:

Thanks Igor,I can pseudo-streaming H.264/MP3 files after update from 1.2.5 to
1.3.9.
Do you plan to back port this change to 1.2.x stable version or i have to wait
for the 1.4.x.

I can not say if will it be merged in 1.2.x, but 1.3.x is quite stable.
Also you can use this patch for 1.2.x:
http://trac.nginx.org/nginx/changeset/4821/nginx


Igor S.

On 2012-11-27 23:32, Valentin V. Bartenev wrote:

Don’t worry, it’s indeed minor adjustments while applying.
It should work as well as with the previous nginx version.

Great, thanks for confirmation. If anyone is interested for reasons of
convenience, I applied the patch to nginx 1.3.9, resolved the rejects
and did a fresh unified diff.

https://www.schug.net/dist/nginx/patch.spdy-53-1.3.9.txt

So feel free to use it until patch.spdy-54.txt is being released at
http://nginx.org/patches/spdy/

-cs

Hello!

On Tue, Nov 27, 2012 at 09:58:42PM +0100, Paweł Marzec wrote:

…/nginx_upload_module-2.2.0/ngx_http_upload_module.c:2687: error:
Error 1
make[1]: Leaving directory `/root/nginx-1.3.9’
make: *** [build] Error 2

any ideas?

Looks like upload module depends on request body reading code
internal details, and it needs updating.


Maxim D.

Thank you for the patch. I can pseudo-streaming H.264/MP3 files on 1.2.5
now. But I just noticed that still some of H.264/MP3 files converted by
FFmpeg has no sound even testing on 1.3.9. I can send you a sample file
if you need it.

Sheng

On Wednesday 28 November 2012 13:45:54 Christoph Schug wrote:

On 2012-11-27 23:32, Valentin V. Bartenev wrote:

Don’t worry, it’s indeed minor adjustments while applying.
It should work as well as with the previous nginx version.

Great, thanks for confirmation. If anyone is interested for reasons of
convenience, I applied the patch to nginx 1.3.9, resolved the rejects
and did a fresh unified diff.

Rejects? Are you sure? Could you show me them? Because I see only some
small offsets and two little fuzz:

vbart@vbart-laptop nginx-1.3.9 % patch -p0 < patch.spdy.txt
patching file src/http/ngx_http_spdy.h
patching file src/http/ngx_http.h
Hunk #1 succeeded at 24 (offset 1 line).
Hunk #2 succeeded at 39 (offset 1 line).
Hunk #3 succeeded at 94 (offset 8 lines).
Hunk #4 succeeded at 113 with fuzz 1 (offset 10 lines).
Hunk #5 succeeded at 121 (offset 10 lines).
patching file src/http/ngx_http_parse.c
patching file src/http/modules/ngx_http_ssl_module.c
patching file src/http/modules/ngx_http_limit_req_module.c
patching file src/http/ngx_http_spdy_module.c
patching file src/http/ngx_http_request.c
Hunk #10 succeeded at 1986 (offset 3 lines).
Hunk #11 succeeded at 3138 (offset 3 lines).
patching file src/http/ngx_http_spdy_filter_module.c
patching file src/http/ngx_http_spdy_module.h
patching file src/http/ngx_http_request.h
Hunk #1 succeeded at 270 (offset 1 line).
Hunk #2 succeeded at 423 (offset 3 lines).
patching file src/http/ngx_http_core_module.c
Hunk #1 succeeded at 2130 (offset 1 line).
Hunk #2 succeeded at 4082 (offset 1 line).
patching file src/http/ngx_http_upstream.c
patching file src/http/ngx_http_core_module.h
patching file src/http/ngx_http_request_body.c
Hunk #1 succeeded at 41 with fuzz 2 (offset 2 lines).
Hunk #2 succeeded at 476 (offset 5 lines).
patching file src/http/ngx_http_spdy.c
patching file src/http/ngx_http.c
patching file auto/sources
patching file auto/options
patching file auto/modules

No rejects.

wbr, Valentin V. Bartenev

http://nginx.org/en/donation.html

Hello!

On Wed, Nov 28, 2012 at 02:54:02PM +0400, Valentin V. Bartenev wrote:

small offsets and two little fuzz:

vbart@vbart-laptop nginx-1.3.9 % patch -p0 < patch.spdy.txt
patching file src/http/ngx_http_spdy.h
patching file src/http/ngx_http.h
Hunk #1 succeeded at 24 (offset 1 line).
Hunk #2 succeeded at 39 (offset 1 line).
Hunk #3 succeeded at 94 (offset 8 lines).
Hunk #4 succeeded at 113 with fuzz 1 (offset 10 lines).
Hunk #5 succeeded at 121 (offset 10 lines).

[…]

No rejects.

What about just producing a new patch? It would be easier for
anyone who use it.

There is more than one patch(1) implementations floating around,
and I wouldn’t be surprised fuzz in one of them will be reject in
another one.


Maxim D.

On Wednesday 28 November 2012 16:14:16 Maxim D. wrote:

and did a fresh unified diff.
Hunk #4 succeeded at 113 with fuzz 1 (offset 10 lines).
and I wouldn’t be surprised fuzz in one of them will be reject in
another one.

Ok, you’re right, I haven’t been thought that this time the problem
is so serious.

The patch was updated:
http://nginx.org/patches/spdy/patch.spdy-54.txt

wbr, Valentin V. Bartenev

http://nginx.org/en/donation.html

Hello!

On Wed, Nov 28, 2012 at 07:23:25PM +0900, Sheng.Zheng wrote:

Thank you for the patch. I can pseudo-streaming H.264/MP3 files on
1.2.5 now. But I just noticed that still some of H.264/MP3 files
converted by FFmpeg has no sound even testing on 1.3.9. I can send
you a sample file if you need it.

Yes, please provide links to a couple of sample files which
has problems with streaming.


Maxim D.

Hello sheng,

I am not an expert on nginx, but the streaming of “something (mp3,
h.264, etc)” it’s not indipendent from the content/codec, how to
decode the streaming it’s a client/consumer
aspect, or no?

On 11/27/12, Sheng.Zheng [email protected] wrote:

Sheng


nginx mailing list
[email protected]
nginx Info Page


Cordiali saluti,
Valeriano Cossu

Regards,
Valeriano Cossu

cell: (+39) 3462187419
skype: valerianocossu

On Wed, Nov 28, 2012 at 9:54 PM, Valeriano Cossu
[email protected] wrote:

Hello sheng,

I am not an expert on nginx, but the streaming of “something (mp3,
h.264, etc)” it’s not indipendent from the content/codec, how to
decode the streaming it’s a client/consumer
aspect, or no?

I believe it’s to support start= parameter.