naviserver-devel

[naviserver-devel] ns_headers, ns_startcontent

[Vasiljevic Z. <zv...@ar...>]

Hi!

I'm referring to this entry in the ChangeLog:

	* nsd/tclresp.c: Add the -binary switch to ns_headers to signify  
that you
	intend sending binary data (probably with ns_write) and that the
	mime-type header should not have a charset declaration appended.

Eh? I cannot see that in the code. The current implementation
(as in CVS) simply decides this on existence of the last
(optional) paramater that would specify length of the response
to be included in Content-Length header.

As this is now implemented, I cannot create output headers that
have no Content-Length inside, although I would like to send
binary data AND I do not know how large that data would be
in advance.

I suggest either adding that option OR use the simple convention
of length=-1 that would specify binary datastream of unknown length.

Until we sort this out, I will just check-in the simpler (latter)
variant. If somebody objects I will rewrite it to "-binary" switch.

In conjuction to this, I would also like to know what is the purpose
of the "ns_startcontent" command? I cannot see that documented nor I
do understand how is this supposed to be used with ns_headers and  
ns_write.

Cheers
Zoran

Re: [naviserver-devel] ns_headers, ns_startcontent

[Stephen D. <sd...@gm...>]

On 9/29/07, Vasiljevic Zoran <zv...@ar...> wrote:
> Hi!
>
> I'm referring to this entry in the ChangeLog:
>
>         * nsd/tclresp.c: Add the -binary switch to ns_headers to signify
> that you
>         intend sending binary data (probably with ns_write) and that the
>         mime-type header should not have a charset declaration appended.
>
> Eh? I cannot see that in the code. The current implementation
> (as in CVS) simply decides this on existence of the last
> (optional) paramater that would specify length of the response
> to be included in Content-Length header.
>
> As this is now implemented, I cannot create output headers that
> have no Content-Length inside, although I would like to send
> binary data AND I do not know how large that data would be
> in advance.
>
> I suggest either adding that option OR use the simple convention
> of length=-1 that would specify binary datastream of unknown length.
>
> Until we sort this out, I will just check-in the simpler (latter)
> variant. If somebody objects I will rewrite it to "-binary" switch.
>
> In conjuction to this, I would also like to know what is the purpose
> of the "ns_startcontent" command? I cannot see that documented nor I
> do understand how is this supposed to be used with ns_headers and
> ns_write.
>



Does this make sense:

  http://naviserver.sourceforge.net/n/naviserver/files/ns_write.html

Re: [naviserver-devel] ns_headers, ns_startcontent

[Vasiljevic Z. <zv...@ar...>]

On 29.09.2007, at 12:22, Stephen Deasey wrote:

>
> Does this make sense:

It does make sense but it does not answer either
of my questions.

Still: what good is ns_startcontent when you have
ns_headers and ns_write? How to handle binary streams
of unknown sizes i.e. how NOT to get Content-Length
included in headers by the server code?

Cheers,
Zoran

Re: [naviserver-devel] ns_headers, ns_startcontent

[Stephen D. <sd...@gm...>]

On 9/29/07, Vasiljevic Zoran <zv...@ar...> wrote:
>
> On 29.09.2007, at 12:22, Stephen Deasey wrote:
>
> >
> > Does this make sense:
>
> It does make sense but it does not answer either
> of my questions.

> How to handle binary streams
> of unknown sizes i.e. how NOT to get Content-Length
> included in headers by the server code?


Then I guess that page doesn't make sense, because I thought it
explained the situation  :-)

As far as I can tell, we already support streaming binary data, both
to HTTP 1.0 and 1.1 clients (and also to non-HTTP custom clients).

Can you show some example code? What did you expect would happen, what
actually happened?


> Still: what good is ns_startcontent when you have
> ns_headers and ns_write?


I don't think it makes sense any more.

It came from the old ArsDigita encoding patches to aolserver-3.x. The
idea was you would write your own headers using ns_write, then you'd
call ns_startcontent to signify that you'd finished writing headers
and were now going to write content in some particular encoding, so
the ns_write command should now encode the data you pass it.  Headers
should always be ascii.

Here's an example:

http://naviserver.cvs.sourceforge.net/naviserver/naviserver/tests/tclresp.test?revision=1.14&view=markup#l_496

This is all handled automatically now, and ns_startcontent should not be used.

Re: [naviserver-devel] ns_headers, ns_startcontent

[Vasiljevic Z. <zv...@ar...>]

On 29.09.2007, at 15:32, Stephen Deasey wrote:
>
> As far as I can tell, we already support streaming binary data, both
> to HTTP 1.0 and 1.1 clients (and also to non-HTTP custom clients).
>
> Can you show some example code? What did you expect would happen, what
> actually happened?

OK. Very simple. I must generate/send headers with
ns_headers but without Content-Length element.
Later, I get [bs_conn channel] and use it to pump
the data to remote from custom C-code writing to the
connection channel. The length of data is not known
in advance, hence I cannot have Content-Length set
in output headers. At the moment there is no way to
do that. It was before. Some later chnage(s)  disabled
it. So I changed ns_headers to allow -1 for optional
length argument in which case Content-Length is removed
from output headers before flushing them.

Then I saw the ChangeLog entry about "-binary" flag to
ns_headers but I could not find it in the code.
Hence the question.... (still not answered)



>
>
>> Still: what good is ns_startcontent when you have
>> ns_headers and ns_write?
>
>
> I don't think it makes sense any more.
>
> It came from the old ArsDigita encoding patches to aolserver-3.x. The
> idea was you would write your own headers using ns_write, then you'd
> call ns_startcontent to signify that you'd finished writing headers
> and were now going to write content in some particular encoding, so
> the ns_write command should now encode the data you pass it.  Headers
> should always be ascii.
>
> Here's an example:
>
> http://naviserver.cvs.sourceforge.net/naviserver/naviserver/tests/ 
> tclresp.test?revision=1.14&view=markup#l_496
>
> This is all handled automatically now, and ns_startcontent should  
> not be used.
>

Why don't we declare it deprecated? It just confuses people
(at least it confused me).

Cheers
Zoran

Re: [naviserver-devel] ns_headers, ns_startcontent

[Stephen D. <sd...@gm...>]

On 9/29/07, Vasiljevic Zoran <zv...@ar...> wrote:
>
> On 29.09.2007, at 15:32, Stephen Deasey wrote:
> >
> > As far as I can tell, we already support streaming binary data, both
> > to HTTP 1.0 and 1.1 clients (and also to non-HTTP custom clients).
> >
> > Can you show some example code? What did you expect would happen, what
> > actually happened?
>
> OK. Very simple. I must generate/send headers with
> ns_headers but without Content-Length element.
> Later, I get [bs_conn channel] and use it to pump
> the data to remote from custom C-code writing to the
> connection channel. The length of data is not known
> in advance, hence I cannot have Content-Length set
> in output headers. At the moment there is no way to
> do that. It was before. Some later chnage(s)  disabled
> it. So I changed ns_headers to allow -1 for optional
> length argument in which case Content-Length is removed
> from output headers before flushing them.


This was really a problem with the underlying Ns_ConnWrite* code
distinguishing between no length and zero length, and mainly because
the last place in the server that flushes headers is the 'ns_conn
channel' command, which must do the flush because subsequent writes
won't go through the Ns_ConnWrite* stack where usually the headers are
sent along with the first data write.

Actually it's quite complicated (which is a bad sign...) with many
corner cases. Now however it's perfect  :-)


> Then I saw the ChangeLog entry about "-binary" flag to
> ns_headers but I could not find it in the code.
> Hence the question.... (still not answered)


I think what happened here is after I added the -binary switch,
basically for mime-type header handling, it occurred to me that it
only makes sense to supply an explicit length when you were sending
binary data. If you specify a length for character data you've already
got it wrong -- you can't tell what the final length will be after
encoding, compression etc. So, I guessed binaryness from the presence
of the length arg.

Unfortunately that doesn't allow binary streaming, for example via
ns_conn channel (which seems more likely than ns_write). So,
ns_headers -binary is back.


>
> ns_startcontent
>
> Why don't we declare it deprecated? It just confuses people
> (at least it confused me).
>


I'm pretty sure it's unneeded, but I've really only touched the
encoding stuff as needed for the IO changes, and some minor cleanups.
There's some more to do and encoding is a real headache...

Still, it's missing from the man pages and I added a note in the source.