At least when sent POST requests from certain browsers, Comanche doesn't
read in the last two bytes of the request.
I'm not sure what the reason is. But it points out a problem in the way
socket shutdown is done on the Unix VM. It's hard to fix; I've tried
twice and ended up with a VM that likes to core dump. It would be much
if those two bytes could somehow get read, and thus make the problem
fade back into the real of theoretical problems instead of practical
ones.
The upshot is that if you run a Swiki on Linux, and you edit a page,
then sometimes you won't get all of the reply back.
Lex
Bijan Parsia <[EMAIL PROTECTED]> wrote:
> At 6:37 PM -0500 1/30/00, Lex Spoon wrote:
>
> >"Bolot Kerimbaev" <[EMAIL PROTECTED]> wrote:
> >> > Yep, turns out to be a simple little 'off by one' bug. Add 2, rather than
> >> 3 :)
> >>
> >> Bijan, thanks for finding this bug. Actually, I had found it a while ago,
> >> but was waiting for a bunch of this to accumulate before I release Comanche
> >> 4.5. I ran into this when I was doing some XML-RPC stuff between two
> >> Squeaks.
> >>
> >
> >Hey, would this by any chance cause a net *two* extra bytes to be read
> >in for posts?
>
> Er.. details? Where, which, when, what?
>
> > If so, it could solve another problem we've run into....
> >(Not a bug on Comanche's part, but it's hard to fix)
>
> Er..I don't quite see how. It's only one char off.
>
> Hmm. Unless...Ok. Are you stripping, replacing or reversing crs with
> linefeeds? If you had a crcrlf sequence after the...oops. That wouldn't
> necessarly do it either. Fudge.
>
> I think it would be a really good idea to get some unit tests into
> Comanche. It would make this sort of thing easier to detect. And when
> dealing with this sort of structured text protocals, it's really easy to
> simulate the right input. It would make porting a touch easier too.
>
> Anyone up for this? Comanche has already gotten quite big, but if loads of
> people pitched in we could probably come up with a suitable set of unit
> tests.
>
> Cheers,
> Bijan.
