Re: ngx.location.capture

agentzh

Hello!

On Wed, Mar 20, 2013 at 4:37 AM, Vincent Chavelle
<vincent...@gmail.com> wrote:
> Thanks for your reply, I finally investigate and the problem comes from
> Content-Type header.
>
> In my case the first request has the following
> Content-Type: multipart/form-data; boundary=cpcaupipxvqdfnsrxugwvraaudntfpal
>

Yeah, this is a common mistake for ngx_lua beginners.

> And ngx.location.capture pass the same header to the subrequest.
> I have tried to use ngx.header for override it but doesn't seems to work.
> Do you have any idea to ignore content-type header from the request ?
>

If you read the official documentation for ngx.header carefully,
you'll notice that it is for *response* headers rather than request
headers.

You can either call ngx.req.set_header() to (temporarily) modify the
main request's request header before calling ngx.location.capture or
use proxy_set_header in your subrequest's location (if you're using
ngx_proxy in the subrequest).

Best regards,
-agentzh

vincent.chavelle

Cool! Thanks again.

I'm trying to deploy your amazing lua resty upload module (successfully deployed on local) to a remote server (same configuration, but with https).

It failed, due to various errors on socket access (closed, file exists etc...) sock:receiveuntil

013/03/21 12:15:51 [alert] 28039#0: *7 epoll_ctl(1, 18) failed (17: File exists), client: X.X.X.X, server: test.com, request: "POST /api/new.json HTTP/1.1", host: "test.com"

I removed https, and all errors were gone.

HTTPS not supported? :'(

Thanks for your time

Vincent Chavelle

On Wed, Mar 20, 2013 at 8:27 PM, agentzh <age...@gmail.com> wrote:

Hello!

On Wed, Mar 20, 2013 at 4:37 AM, Vincent Chavelle
<vincent...@gmail.com> wrote:
> Thanks for your reply, I finally investigate and the problem comes from
> Content-Type header.
>
> In my case the first request has the following
> Content-Type: multipart/form-data; boundary=cpcaupipxvqdfnsrxugwvraaudntfpal
>

Yeah, this is a common mistake for ngx_lua beginners.

> And ngx.location.capture pass the same header to the subrequest.
> I have tried to use ngx.header for override it but doesn't seems to work.
> Do you have any idea to ignore content-type header from the request ?
>

If you read the official documentation for ngx.header carefully,
you'll notice that it is for *response* headers rather than request
headers.

You can either call ngx.req.set_header() to (temporarily) modify the
main request's request header before calling ngx.location.capture or
use proxy_set_header in your subrequest's location (if you're using
ngx_proxy in the subrequest).

Best regards,
-agentzh

agentzh

Hello!

On Thu, Mar 21, 2013 at 5:24 AM, Vincent Chavelle
<vincent...@gmail.com> wrote:
> I'm trying to deploy your amazing lua resty upload module (successfully
> deployed on local) to a remote server (same configuration, but with https).
> It failed, due to various errors on socket access (closed, file exists
> etc...) sock:receiveuntil
> 013/03/21 12:15:51 [alert] 28039#0: *7 epoll_ctl(1, 18) failed (17: File
> exists), client: X.X.X.X, server: test.com, request: "POST /api/new.json
> HTTP/1.1", host: "test.com"
> I removed https, and all errors were gone.
>

Please provide a minimized but still complete example (both nginx
configuration and Lua code) that can reproduce the problem.

Can you reproduce this issue with the latest Nginx stable version 1.2.7?

Are you enabling the SPDY patch?

Also, providing more raw nginx error log messages could be helpful. Do
not summarize the error messages yourself, which leads to loss of
important details.

Best regards,
-agentzh

vincent.chavelle

You are right, it's the SPDY patch fault, I use nginx/1.3.14...

They are a problem with:

listen 443 spdy ssl;

But not with:

listen 443 ssl;

I use the example in https://github.com/agentzh/lua-resty-upload

"You can use the lua-resty-string library to compute SHA-1 and MD5 digest of the file data incrementally. Here is such an example"

I pass in this block:

if not typ then
         ngx.say("failed to read: ", err)
         return
    end

"failed to read: closed"

"failed to read: File exists"

Don't hesitate if I can help more.

Thanks

Vincent Chavelle

On Thu, Mar 21, 2013 at 8:28 PM, agentzh <age...@gmail.com> wrote:

Hello!

On Thu, Mar 21, 2013 at 5:24 AM, Vincent Chavelle
<vincent...@gmail.com> wrote:
> I'm trying to deploy your amazing lua resty upload module (successfully
> deployed on local) to a remote server (same configuration, but with https).
> It failed, due to various errors on socket access (closed, file exists
> etc...) sock:receiveuntil
> 013/03/21 12:15:51 [alert] 28039#0: *7 epoll_ctl(1, 18) failed (17: File
> exists), client: X.X.X.X, server: test.com, request: "POST /api/new.json
> HTTP/1.1", host: "test.com"
> I removed https, and all errors were gone.
>

Please provide a minimized but still complete example (both nginx
configuration and Lua code) that can reproduce the problem.

Can you reproduce this issue with the latest Nginx stable version 1.2.7?

Are you enabling the SPDY patch?

Also, providing more raw nginx error log messages could be helpful. Do
not summarize the error messages yourself, which leads to loss of
important details.

Best regards,
-agentzh

agentzh

Hello!

On Fri, Mar 22, 2013 at 3:42 AM, Vincent Chavelle wrote:
> You are right, it's the SPDY patch fault, I use nginx/1.3.14...
> They are a problem with:
> listen              443 spdy ssl;
> But not with:
> listen              443 ssl;
>

The SPDY patch is still considered highly experimental and known to
have quite a few issues with ngx_lua (not just your report).

I haven't got the tuits to look into such SPDY related issues since I
don't have the time right now to fix issues in the SPDY patch at the
moment. I'm sorry.

Best regards,
-agentzh

vincent.chavelle

Hello

No problem, thank you very much.

Vincent Chavelle

On Fri, Mar 22, 2013 at 8:00 PM, agentzh <age...@gmail.com> wrote:

Hello!

On Fri, Mar 22, 2013 at 3:42 AM, Vincent Chavelle wrote:
> You are right, it's the SPDY patch fault, I use nginx/1.3.14...
> They are a problem with:
> listen 443 spdy ssl;
> But not with:
> listen 443 ssl;
>

The SPDY patch is still considered highly experimental and known to
have quite a few issues with ngx_lua (not just your report).

I haven't got the tuits to look into such SPDY related issues since I
don't have the time right now to fix issues in the SPDY patch at the
moment. I'm sorry.

Best regards,
-agentzh