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 <jmhe...@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
