Hi Chris and all,
Am 13.06.26 um 17:57 schrieb Christopher Schultz:
All,
Here is jk_sb_gets:
int jk_sb_gets(jk_sockbuf_t *sb, char **ps)
{
int ret;
if (sb) {
while (1) {
unsigned i;
for (i = sb->start; i < sb->end; i++) {
if (JK_LF == sb->buf[i]) {
if (i > sb->start && JK_CR == sb->buf[i - 1]) {
sb->buf[i - 1] = '\0';
}
else {
sb->buf[i] = '\0';
}
*ps = sb->buf + sb->start;
sb->start = (i + 1);
return JK_TRUE;
}
}
if ((ret = fill_buffer(sb)) < 0) {
return JK_FALSE;
}
else if (ret == 0) {
*ps = sb->buf + sb->start;
if ((SOCKBUF_SIZE - sb->end) > 0) {
sb->buf[sb->end] = '\0';
}
else {
sb->buf[sb->end - 1] = '\0';
^^^^ Look here
}
return JK_TRUE;
}
}
}
return JK_FALSE;
}
Take a look at the line indicated above.
If we don't have enough space in the buffer, we overwrite the final byte
of data with a null-terminator. While this is safe from a memory
perspective, it will corrupt the actual data.
My question is "what other choice do we have?"
I'm not familiar enough with the entirety of mod_jk to know if we can
simply return JK_FALSE in this situation, indicating that "something
bad" has happened.
My guess is that this happens either rarely or never, as we aren't
getting complaints about corrupted data transfer in mod_jk.
WDYT?
jk_sb_gets() is only called once, in common/jk_ajp12_worker.c, so only
for the very outdated AJP12. The calling code already handles returning
false by itself logging an error and returning JK_FALSE. So IMHO it is
save to let truncation be handled as proposed.
IMHO if we want to keep mod_jk alive, we could think about announcing
EOL for AJP12 and eg. remove it next year. The code calls it deprecated
at least for a decade now, the docs say it's obsolete. I never saw it in
use.
in mod_jk land we only have to care what mod_jk / isapi redirector users
do with it. We do not have an API to keep stable (like a library), only
configuration behavior should be kept stable if possible. Nevertheless I
think we can get rid of very outdated behavior like we did before (NSAPI
module, Domino, Netware support).
Best regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
