Ah, ok. I'm not sure where I got that line to mark header_only from,
probably looking at some other code. Once I commented that out, I
discovered where the content length was coming from, I had an error
page for the 302 response that I hadn't realized I'd put in there and
of course it makes sense in this case that there was a response length
but no body because I had forced the flag. Code adjusted, no more
invalid response errors on i-devices! Thanks for the help Maxim.

jmh

On Fri, Jan 13, 2023 at 11:19 PM Jeff Heisz <jmheisz@gmail.com> wrote:
>
> 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