With current version any parsing does not work

jacksonh / manos

Manos is an easy to use, easy to test, high performance web application framework that stays out of your way and makes your life ridiculously simple.

Other

455 stars 61 forks source link

With current version any parsing does not work #99

Closed konrad-kruczynski closed 13 years ago

konrad-kruczynski commented 13 years ago

With git's tip version even hello world example raises an error: Exception while parsing System.ArgumentException: Can't move past end of buffer.

Workaround is to turn off byte number checking in Manos' stream, however that should not happen anyway.

ghost commented 13 years ago

Can't reproduce, sorry.

konrad-kruczynski commented 13 years ago

What mono's version do you use? Mine is 4ad303e2b788b33bceeb.

ghost commented 13 years ago

260177c0347d8eef68649d32553c7d370084f4db here. It also worked with a version about a week old. Can you post steps to reproduce?

konrad-kruczynski commented 13 years ago

Thanks, I'll try it. I will also try to provide steps if it still fails, but pls wait a couple of days as I will be very busy for the moment. Btw, I have an issue with some responses, which are produced on another thread (at least I think so) using: Boundary.Instance.ExecuteOnTargetLoop(() => PerformDownload(ctx, session, pathAndFileName)); Is it proper way to do it? When quite a long content is written to ctx.Response in PerformDownload method, received data is malformed as if Response was close too early (by some kind of pipe mechanism or sth, I don't know). Can you tell me what is the proper method for making asynchronous writes to given ctx.Response? I'll appreciate that.

ghost commented 13 years ago

You'd have to post a larger piece of code, sorry. But the pipeline does have a rather large number of problems, yes.

konrad-kruczynski commented 13 years ago

I'll try to provide both in a couple of days (and make second one on separate issue).

jacksonh commented 13 years ago

Yeah I am also unable to reproduce using mono-2-10-2

toptensoftware commented 13 years ago

Happens for me on posting pretty much any form data. For example, posting this form does it:

<html>
<head>
<title>Blah</title>
</head>
<body>
<h1>Test Form</h1>
<form method="post" action="/Home/Form"> 
  <p>Name: <input type="text" name="name" id="name" value="foo" /></p>
  <p>Email: <input type="text" name="email" id="email" value="foo@bar.com" /></p>
  <button type="submit">OK</button>
</form>
</body>
</html>

Running under Windows, using Mono 2.8 posix dll and head Manos from github

toptensoftware commented 13 years ago

I found the cause of this. In HttpParser.Execute, when a form data is posted (like my example above), this routine runs twice - first time parsing the headers, second time with the form data. First time works, second time fails as follows:

The passed in ByteBuffer has a length of 28
The first byte is read at line 201 byte ch = data.ReadByte()
Reading the byte decrements the byte buffers length to 27
Control goes to case State.body_identity where pe and content_length are both 28
RaiseOnBody is called successfully but the following line tries to skip 28 bytes.

Because of the previous decrement when the first byte was read, the byte buffer fails saying you cant skip 28 bytes when there's only 27 left.

I've hacked my copy to do data.Skip(to_read-1) which gets me by for the moment but not sure if that's the correct overall fix.

toptensoftware commented 13 years ago

@Myeisha, your comment:

But the pipeline does have a rather large number of problems, yes.

is concerning, what other sorts of problems are we going to encounter?

jacksonh commented 13 years ago

Seems to work fine on Linux/OSX

ghost commented 13 years ago

Nope, posting is borked. I haven't looked at that earlier on.

jacksonh commented 13 years ago

Ah, that is right this copy is a little out of date.

ghost commented 13 years ago

@toptensoftware: thanks for the fix. Turns out, this is the correct way to do it - we just never noticed because the ByteBuffer performed less rigorous checks before the IO split.

Concerning the pipelines: right now, the pipeline is basically useless, and if you use it with sync blocks, it bites you. This has to be fixed, and I have a concept ready, but I am a bit short on time to do this right now. Sorry.