Advance print function

[aviramc]

Added the following "advance" print functions ngx.rawprint and nginx.rawprint_headers.
ngx.rawprint sends data directly to the client without passing it through the Nginx filter chains.
ngx.rawprint_headers allows to send send the response headers (including the status line) directly to the client in a raw fashion (this meaning that they should be separated by newlines and that the end of the headers must be marked with a double newline).
These are used by me in order to implement some advance features.

[agentzh]

I don't think I really like this feature because bypassing the Nginx output filter chain will risk breaking the HTTP protocol state (like HTTP keepalive and etc) maintained by the Nginx core itself. I think proper websocket support is the right way to go here.

[aviramc]

What do you mean by "proper websocket support"?

[agentzh]

I mean support for WebSocket: http://en.wikipedia.org/wiki/WebSocket

[agentzh]

@aviramc It'll be great if you can elaborate your "advance features" :) I'm currently working on the raw request socket API in ngx_lua, upon which one can easily implement protocols like WebSocket in pure Lua. But this API currently requires the caller has already sent out a response header and has read the whole request body. I need really good reasons to relax these restrictions :)

[aviramc]

Hello!

I currently have my own copy of ngx_lua, which holds the following features:

• The advance print functions.
• The same socket can be used for receive and send at the same time from two threads (changed the busy flag to receive_busy and send_busy and some more changes).
• Subrequest "streaming" (when the subrequest is a proxy_pass request).

And some more tiny features.
I'm currently working on SSL support for coscokets. When this is done, I'll merge everything to the latest version and create a pull request. Is this okay with you?

[agentzh]

@aviramc I've committed the "websocket" git branch which implements the ngx.req.socket(true) API which returns a downstream cosocket that is writable. So this can already do what your ngx.rawprint does. But this API requires the response header is already sent, which means that it cannot do what your ngx.rawprint_headers does. Could you elaborate why you need the capability to construct the raw response header yourself in the first place?

Regarding splitting the reading and writing parts of a cosocket object, I'd love to merge this enhancement.

Regarding the "streaming subrequest" feature, I'd like to include it too.

I'm glad that you're working on the SSL support for cosockets. That's high in my priority as well :)

[aviramc]

@agentzh I use ngx.rawprint_headers in order to form responses that Nginx doesn't support. I've actually implemented a forward proxy using ngx_lua. In a forward proxy, the reply to the "CONNECT" HTTP verb should be "HTTP/1.1 200 Connection established", and that's it - without any headers. So there are two issues here:

1. I'd like to be able to send a different status message of the 200 return code.
2. I'd wouldn't like to send any response headers.

Besides this issue, ngx.req.socket(true) would be great :)

[agentzh]

@aviramc Okay, I see your point now and yes, that is a reasonable example :) I'll try allowing sending raw response headers directly via the cosocket object returned by ngx.req.socket(true).

[agentzh]

@aviramc I've just committed a patch to master that allows sending raw http response headers via ngx.req.socket(true). Please check it out to confirm it works for me :) Thanks!

[aviramc]

@agentzh I've viewed the patch. The only problem I have with it is that it requires to read the entire request body before actually performing the request. This doesn't allow me to implement the forward proxy.
I've actually written a patch for this, and I'll post a pull request in the next few minutes :)

[agentzh]

Please check out if the commit ebf9cc8 works for you.

[aviramc]

It works, thanks

[agentzh]

The only downside (that I'm aware of) with my current approach is that we can no longer update r->request_length field when we use ngx.req.socket(true) to read the raw request body data. Fortunately this field is only used for logging purposes at least in the Nginx core.

[agentzh]

I'm closing this.