[ naviserver-Feature Requests-1184271 ] Add "ns_conn flush"

[SourceForge.net <no...@so...>]

Feature Requests item #1184271, was opened at 2005-04-16 16:03
Message generated for change (Comment added) made by vasiljevic
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=719009&aid=1184271&group_id=130646

Category: Tcl-API
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Zoran Vasiljevic (vasiljevic)
Assigned to: Zoran Vasiljevic (vasiljevic)
Summary: Add "ns_conn flush"

Initial Comment:
This should internally invoke Ns_ConnFlushHeaders
effectively spitting out the headers and any content
not sent already.

The call can be executed at any time, but the headers 
are sent only once.

The call should return the integer equivalent of NS_OK
or NS_ERROR to be compatible with ns_return calls.

Implementation is trivial and I will check this in.
If there are serious complaints, I will revert the changes.

----------------------------------------------------------------------

>Comment By: Zoran Vasiljevic (vasiljevic)
Date: 2005-04-18 15:16

Message:
Logged In: YES 
user_id=95086

?????????

When/who added THAT?
And how the heck I did not see this before????

lexxsrv:nscp 2> ns_headers
wrong # args: should be "ns_headers connid status ?type len?"

Hrmpffff... ok, the "connid" should be removed but that
is another story...



----------------------------------------------------------------------

Comment By: Stephen Deasey (sdeasey)
Date: 2005-04-18 15:07

Message:
Logged In: YES 
user_id=87254


No need, it's been there all the time...  :-)



----------------------------------------------------------------------

Comment By: Zoran Vasiljevic (vasiljevic)
Date: 2005-04-18 11:33

Message:
Logged In: YES 
user_id=95086

Yeah. Basically, the

  ns_headers status ?type len?

type of thing is what I have already implemented in our custom code.
If there is no objection to this type of command, I can add it by 
copying our working code. 

----------------------------------------------------------------------

Comment By: Stephen Deasey (sdeasey)
Date: 2005-04-17 22:42

Message:
Logged In: YES 
user_id=87254


Ns_ConnSend() (which is called by Ns_ConnWrite() <-
Ns_WriteConn()) does mention that it sends any queued
write-behind data, but as far as I can tell this buffer
exclusivley contains the response headers.  Therefore,
flushheaders would be a more accurate description than flush
alone.

Anyhow, I think what you're looking for is:

    ns_headers status ?type len?

Which basically calls Ns_ConnSetRequiredHeaders(),
Ns_ConnFlushHeaders(), which is exactly what you want.

I don't know why we didn't see this earlier...  :-)

(Actually, I think this means conn.c and tclresp.c could do
with some improvement)



----------------------------------------------------------------------

Comment By: Zoran Vasiljevic (vasiljevic)
Date: 2005-04-17 10:01

Message:
Logged In: YES 
user_id=95086

You are right. I am still looking for the way to compose correct
set of headers and push them to remote peer w/o sending the
content and closing the connection socket.

The application for this is: you get the request, set up response
headers, send them over, use "ns_conn channel" to get the
channel and then use this channel to communicate with the remote.
This is kindof poor-man´s custom protocol implementation.

Basically I also needed an equivalent of Ns_ConnSetRequiredHeaders
but I did not succeed  to put this somewhere logically. Therefore I 
skipped that and now I do something like:

   set oh [ns_conn outpoutheaders]
   ns_set put $oh Content-Length" xxxx
   ns_set put $oh Content-Type yyyy
   ns_conn status 200
   ns_conn flush

There are other required headers (time, server etc) but this I 
just ignore for now. There should also be a way to get those
in the set returned  by the [ns_conn outputheaders].  That 
would be actually a good idea, instead of returning the empty
set. Right?

Now, concerning the Ns_ConnFlushContent...
I`ve greped thru the code but this call is not used anywhere,
It reads:

    *      Finish reading waiting content.

which leads me to believe that this is used to discard the non-processed
content received from the remote (the opposite direction).
This one could be the mechanism for "ns_conn discardcontent" but as
you told us before, this is not  realy needed in 4.x series servers. Hence
I removed our private implementation and rely on the fact that the server
already consumed all data from the socket being sent by the remote.
So I did not consider using that call and opening it on the Tcl API level.

The *very* reason I named this command "ns_conn flush" instead of
"ns_conn flushheaders" was because it does soething like:

   Ns_WriteConn(conn, NULL, 0);

which will send *any* queued data (including headers).
Does all of that make sense?


----------------------------------------------------------------------

Comment By: Stephen Deasey (sdeasey)
Date: 2005-04-17 00:33

Message:
Logged In: YES 
user_id=87254


When I first read the subject line I thought you were
refering to this:

http://sourceforge.net/mailarchive/forum.php?thread_id=6736550&forum_id=43966

Turns out that there's a Ns_ConnFlushContent() function.  I
think this needs to be called something like [ns_conn
flushheaders], to avoid confusion.

Not that there's much we can do about it, but even with that
change it could still be a little bit confusing:
FlushHeaders flushes output to the conn, FlushContent drops
input from the conn...



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=719009&aid=1184271&group_id=130646