On 24.08.2006, at 22:08, Stephen Deasey wrote:
Hm... how would you (generally) check for a byte-array?
You can get a byte-array from object but you can't
(without looking into the object type which is really not
something that is portable) say which type of object you
are dealing with.
Sure
On 8/20/06, Zoran Vasiljevic <[EMAIL PROTECTED]> wrote:
On 15.08.2006, at 21:09, Stephen Deasey wrote:
> * is checking for bytearray type a good way to handle binary Tcl
> objects?
Hm... how would you (generally) check for a byte-array?
You can get a byte-array from object but you can't
(withou
Hi Stephen,
> In the documents you serve, do you specify the encoding *within* the
> document, at th etop of the HTML file for example? Or are you serving
> XML in which case the default for that is utf-8 anyway (I think, off
> the top of my head...).
Usually we specify it both ways, in the
Am Sonntag, 13. August 2006 21:44 schrieb Gustaf Neumann:
> Michael Lex schrieb:
> > It's only going to hit you if you use some other encoding than utf-8
> > and then only if you use a HTTP-client, that does not understand
> > chunked encoding. But every web-browser and virtually every other
> > cl
> I would ask the commiter (we will found who that is soon) to always
> update ChangeLog file so we know what is going on. Otherwise it
> is just a waste of time and nerves...
Sorry for not updating the ChangeLog! :-(
Guess I should consider the medical usage part of
http://en.wikipedia.org/wiki
On 15.08.2006, at 21:09, Stephen Deasey wrote:
In the documents you serve, do you specify the encoding *within* the
document, at th etop of the HTML file for example? Or are you serving
XML in which case the default for that is utf-8 anyway (I think, off
the top of my head...).
We put it in
On 8/14/06, Zoran Vasiljevic <[EMAIL PROTECTED]> wrote:
On 14.08.2006, at 22:43, Stephen Deasey wrote:
>
> * Your clients don't understand utf-8, and you serve content in
> multiple languages which don't share a common character set. Sucks to
> be you.
>
I think the whole purpose of that enco
On 14.08.2006, at 22:43, Stephen Deasey wrote:
* Your clients don't understand utf-8, and you serve content in
multiple languages which don't share a common character set. Sucks to
be you.
I think the whole purpose of that encooding mess is this above.
With time this will be less and less
On 8/14/06, Zoran Vasiljevic <[EMAIL PROTECTED]> wrote:
On 14.08.2006, at 15:58, Gustaf Neumann wrote:
> no rocket science (but work)
This is precisely what I was afraid of: work.
Not that I don't like, I just do not have time
for that now.
Moreover, the ns_http is a C-level implementation,
w
On 14.08.2006, at 15:58, Gustaf Neumann wrote:
no rocket science (but work)
This is precisely what I was afraid of: work.
Not that I don't like, I just do not have time
for that now.
Moreover, the ns_http is a C-level implementation,
which means some more work and much more instability
as wh
Zoran Vasiljevic schrieb:
The only trouble is the ton of error messages in the
test suite, as we alone cannot handle chunked encoding
as consumers! I yet have to see if [ns_http] can do that
(I don't think so).
well, implementing chunked encoding in tcl is no rocket science (but work).
howeve
On 14.08.2006, at 14:24, Gustaf Neumann wrote:
Without looking into the code, i would assume that the simplest case
would be to distinguish between cases, where the content-length is
unknown and known.
unknown means: transformation or dynamic content.
for unknown cases i would omit in HTTP/1.
Zoran Vasiljevic schrieb:
On the fly I mean that the message is not encoded in its *entirety*
beforehand, rather it is converted piece-by-piece (hence on-the-fly)
in Ns_ConnWriteVChars().
there are not much options, when the output encoding changes length.
So, what do we have now?
A. For H
On 14.08.2006, at 12:53, Michael Lex wrote:
I think you get Bernd wrong: The problem was, that Bernd wanted
naviserver to return the content in iso-8859-1 encoding. So the number
of bytes and the number of characters should be equal.
The Content-Length has to be the number of bytes returned, bu
I think you get Bernd wrong: The problem was, that Bernd wanted
naviserver to return the content in iso-8859-1 encoding. So the number
of bytes and the number of characters should be equal. The
Content-Length has to be the number of bytes returned, but naviserver
computed the value with string byt
On 14.08.2006, at 12:00, Zoran Vasiljevic wrote:
I must say: the problem is that the *correct* content-length
header is/would-be difficult (or costly in terms of memory
and time) to compute for dynamic content.
Hm... I was too fast, as usual.
If I read Bernds email *carefully*, he says:
On 13.08.2006, at 20:03, Michael Lex wrote:
This chunked-transfer-encoding thing is only a workaround until the
Content-Length bug is fixed.
I've been reading various posts from you, Bernd, Vlad and Stephen
about that...
I must say: the problem is that the *correct* content-length
header is
Michael Lex schrieb:
It's only going to hit you if you use some other encoding than utf-8
and then only if you use a HTTP-client, that does not understand
chunked encoding. But every web-browser and virtually every other
client-software should understand this (It's a MUST part of the rfc).
..
I do not want to remove anything if this breaks anybody's code.
This chunked-transfer-encoding thing is only a workaround until the
Content-Length bug is fixed.
I just want to understand what is going on and how is this
going to hit me (or not) if I start to use this code?
Do I have to know so
On 13.08.2006, at 19:38, Michael Lex wrote:
As I see from the CVS, there were no changes to the C-code there?
Did you have to change the C-code??
I guess, Bernd will have to explain what he ment to do with that...
Bernd is on holiday right now. But i think i can explain the problem.
Bernd sub
As I see from the CVS, there were no changes to the C-code there?
Did you have to change the C-code??
I guess, Bernd will have to explain what he ment to do with that...
Bernd is on holiday right now. But i think i can explain the problem.
Bernd submitted a patch (or better workaround) to preven
On 13.08.2006, at 17:55, Vlad Seryakov wrote:
i think i found it, it is the change about switching into chunked mode
if encoding is used, thus returning the result with length
prepended, so
all test are broken now.
when i disabled it in the sources, some tests are fine now, http.test,
but s
i think i found it, it is the change about switching into chunked mode
if encoding is used, thus returning the result with length prepended, so
all test are broken now.
when i disabled it in the sources, some tests are fine now, http.test,
but still others are broken
Zoran Vasiljevic wrote:
On 13.08.2006, at 18:04, Andrew Piskorski wrote:
Using it shows that between 7/21 and 8/13, there was only one commit
to Naviserver (ignoring its various modules) by anyone other than
"vasiljevic", this one:
2006-08-08 12:07 eide
Ah, Bernd!
* tests/: encoding.test, tclresp.test
On Sun, Aug 13, 2006 at 05:36:33PM +0200, Zoran Vasiljevic wrote:
> That means: somebody did change the code (or the testsuite)
> w/o updating the ChangeLog file. I think I will have to go
> to the mail list archive and check the commit maillist as I
> did not get any emails about what was changed
On 13.08.2006, at 17:28, Vlad Seryakov wrote:
I remember my last chnage in keepalive but i am sure i ran make
test at
that time, it was month ago, after that not sure about other changes
really, not many last time
Your last change was:
2006-07-21 Vlad Seryakov <[EMAIL PROTECTED]>
I remember my last chnage in keepalive but i am sure i ran make test at
that time, it was month ago, after that not sure about other changes
really, not many last time
Zoran Vasiljevic wrote:
On 13.08.2006, at 17:21, Vlad Seryakov wrote:
i am suspecting this happened after encoding patche
On 13.08.2006, at 17:21, Vlad Seryakov wrote:
i am suspecting this happened after encoding patches
WHAT encoding patches??? I see nothing in the ChangeLog!
Zoran
i am suspecting this happened after encoding patches
Zoran Vasiljevic wrote:
Hi!
Please(!) update ChangeLog when commiting new changes.
There is a whole lotta new errors in the test suite
in the form of:
Result was:
200 {} {1
x
0
}
Result should have been (exact matching):
200 1 x
29 matches
Mail list logo
