On 9/29/07, Vasiljevic Zoran <[EMAIL PROTECTED]> 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
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 sim
On 9/29/07, Vasiljevic Zoran <[EMAIL PROTECTED]> 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
>
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
On 9/29/07, Vasiljevic Zoran <[EMAIL PROTECTED]> 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 head
On 4/18/05, Zoran Vasiljevic <[EMAIL PROTECTED]> wrote:
> Hallo friends,
>
> Well, the "ns_headers" seem to do the trick we need. I'm puzzled how I
> did not
> see that call before. I could have saved ourselves much time...
> It says in the function comment that this is an compatibility call.
> Co
