Hello!

I've been trying to debug an issue with a custom nginx module, which
is working 'properly' with desktop browsers but failing on Apple
browsers with an 'invalid response' error message.

I don't know exactly what it doesn't like (so much fun debugging on
i-devices) but I am seeing one specific oddity when tracing the
response from nginx through the desktop debugging console that might
be the cause.

My module communicates with an upstream manager process that signals
the kind of response to be sent along with associated data. The
response that has the issue is when the manager signals a redirect
instead of a content response.

The module extracts the data from the upstream buffer and pushes a
req->headers_out.location header record with the URL from the
upstream. It then sets up the response as:

upstr->headers_in.content_length_n = 0;
// (tried this) ngx_http_clear_content_length(req);
upstr->headers_in.status_n = NGX_HTTP_MOVED_TEMPORARILY;
upstr->state->status = NGX_HTTP_MOVED_TEMPORARILY;
upstr->buffer.pos += url_len;
req->header_only = 1;
upstr->keepalive = 1;

Basically, a response of zero length and a 302 response code,
advancing the upstream buffer position to the end of the URL (no
additional data in the upstream buffer to be processed).

However, when I examine the response through the debugger, I see the
appropriate location header but the content-length is always 32677!
Not zero. Attempting to look at the response shows no data. This is
highly suspicious as to why an error is occuring on the i-device. I
should also mention that the upstream response with the redirect URL
is only 489 bytes, so that's not the source of the value.

What I don't understand is where that content-length is coming from.
Other cases where I set a non-zero length and have data in the
upstream buffer works properly. But for the zero case it doesn't send
any content but sends this non-zero length. From the code above you
can see that I tried deleting the response content length information
in case it was already in place from somewhere but that had no effect.

Any thoughts? I've tried doing some tracing in the nginx core code
itself but so far have not been able to see where this length is
originating from.

Many thanks for any input,

jmh
_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-devel