-
Notifications
You must be signed in to change notification settings - Fork 162
evhtp_request_pause (req) issue #70
Comments
Wow, this is a lot to take in tonight. I may see where things could go wrong. I'm very tired tonight and will look into this tomorrow. But oddly enough, I wrote a detailed example of proper request pausing usage here: https://github.com/criticalstack/libevhtp/blob/develop/examples/example_pause.c Until tomorrow! |
Yeah, sorry I provided so much. Its an issue I'v been stuck with for some time now and struggling with. I'll work on it some more and maybe this will be closed before you get a chance to look at it! =] |
It actually maybe more of a work around than a fix, but I found [1] which instead of calling request_pause, only disabled EV_READ. Its probably an issue on the seafile side, so closing. Thanks for your help. [1] https://sml.zincube.net/~niol/repositories.git/seafile-server/plain/debian/patches/recent-libevhtp |
More information about the issue if interested in reading more. |
Reopening as I remember seeing this issue, and I'm not 100% sure it's a seafile issue. |
Ah, that patch above in (zincube) will only work correctly if the callback where the request is paused is the final one. Otherwise, the API wouldn't know to short-circuit and return back to the function that called the parser. So that person should watch out for that. But I think he's on the right track, here is how pausing works at the moment:
(evhtp_connection_t *)c->flags &= EVHP_CONN_FLAG_PAUSED)
connection->resume_ev = event_new(evbase, -1, EV_READ | EV_PERSIST,
htp__connection_resumecb_, connection); When if (evbuffer_get_length(bufferevent_get_output(c->bev)))
{
HTP_FLAG_ON(c, EVHTP_CONN_FLAG_WAITING);
bufferevent_enable(c->bev, EV_WRITE);
} else {
bufferevent_enable(c->bev, EV_READ | EV_WRITE);
htp__connection_readcb_(c->bev, c);
} If there is pending data on the output buffer, it will only set the bufferevent to
It should be noted that even if /* run user-hook for on_write callback before further analysis */
htp__hook_connection_write_(conn);
/* connection is in a paused state, no further processing yet */
if ((conn->flags & EVHTP_CONN_FLAG_PAUSED))
{
return;
}
/* checks for EVHTP_CONN_FLAG_WAITING, then enables read again */ I think some of the patches above were on the write (get it, "write", not "right"?) track. I do not think the We might want to rearrange some of the code there, I'm thinking something like: /* run user-hook for on_write callback before further analysis */
htp__hook_connection_write_(conn);
/* connection is in a paused state, no further processing yet */
if ((conn->flags & EVHTP_CONN_FLAG_PAUSED))
{
return;
}
if (conn->flags & EVHTP_CONN_FLAG_WAITING) to /* connection is in a paused state, no further processing yet */
if ((conn->flags & EVHTP_CONN_FLAG_PAUSED))
{
return;
}
/* run user-hook for on_write callback before further analysis */
htp__hook_connection_write_(conn);
if (conn->flags & EVHTP_CONN_FLAG_WAITING) and void
evhtp_connection_pause(evhtp_connection_t * c)
{
evhtp_assert(c != NULL);
HTP_FLAG_ON(c, EVHTP_CONN_FLAG_PAUSED);
bufferevent_disable(c->bev, EV_READ | EV_WRITE);
return;
} should be void
evhtp_connection_pause(evhtp_connection_t * c)
{
evhtp_assert(c != NULL);
HTP_FLAG_ON(c, EVHTP_CONN_FLAG_PAUSED);
bufferevent_disable(c->bev, EV_READ);
return;
}
Thoughts? |
Pretty sure adding "Thoughts?" would upset the compiler quite a bit. =] Seriously though the suggested changes look good to me. This is more or less the patch i'v been using up until a few days ago. Rearranging the htp__hook_connection_write_(conn); would make more sense as well. After digesting all the information provided. This is probably what should have occurred in 1.2.9 --> 1.2.10, but its hard to say because of how much the code has changed and how long ago I read that very detailed bug report on why it was done in the first place.(memory a bit spotty on the issue that user was having) Pretty sure it was lost with the project transfer, would have been nice to take another look at it. =/ I didn't expect the rearranging to break anything, but I'v had bad experiences with these assumptions so ran a quick test. Everything looks to be in order. Thank you for digging into this issue. |
EV_WRITE should not be disabled here and was added with the assumption that libevent would automatically start transferring pending data. Much more detailed write up can be found here: Yellow-Camper/libevhtp#70 git-svn-id: svn+ssh://svn.freebsd.org/ports/head@458757 35697150-7ecd-e111-bb59-0022644237b5
EV_WRITE should not be disabled here and was added with the assumption that libevent would automatically start transferring pending data. Much more detailed write up can be found here: Yellow-Camper/libevhtp#70 git-svn-id: svn+ssh://svn.freebsd.org/ports/head@458757 35697150-7ecd-e111-bb59-0022644237b5
EV_WRITE should not be disabled here and was added with the assumption that libevent would automatically start transferring pending data. Much more detailed write up can be found here: Yellow-Camper/libevhtp#70
Do not unset EV_WRITE on the bufferevent when pausing the request. See: #70 for details.
Merged your pull request. Thanks for that. Hopefully, that fixes things. I tested, and nothing went wrong. Cheers! |
That's great news! When do you think you'll be tagging a new release? |
EV_WRITE should not be disabled here and was added with the assumption that libevent would automatically start transferring pending data. Much more detailed write up can be found here: Yellow-Camper/libevhtp#70 git-svn-id: svn+ssh://svn.freebsd.org/ports/head@458757 35697150-7ecd-e111-bb59-0022644237b5
https://github.com/criticalstack/libevhtp/releases/tag/1.2.16 And that's a wrap! |
EV_WRITE should not be disabled here and was added with the assumption that libevent would automatically start transferring pending data. Much more detailed write up can be found here: Yellow-Camper/libevhtp#70 git-svn-id: svn+ssh://svn.freebsd.org/ports/head@458757 35697150-7ecd-e111-bb59-0022644237b5
Details
evhtp_request_pause will freeze current connections from sending data. I don't entirely understand how evhtp works, so this could be a problem in the seafile code and not evhtp, but I'm not positive.
In version 1.2.9, [1] changed to [2] and in every version after it. This caused the main issue that I am experiencing and have reverted the change as shown at [3]. My guess is that EV_WRITE isn't being re enabled when it should. It is very difficult to debug the seafile code though because there isn't any debugging code in it. If you have a suggestion of how to debug the library I am open to suggestions.
[4] [5] is the seafile code using this function, I'm fairly certain [4] is where the bug is occurring. Also want to mention that [6] is a patch I am using that the previous libevhtp developer suggested, which didn't fix the issue unfortunately.
[1] https://github.com/criticalstack/libevhtp/blob/1.2.9/evhtp.c#L1984
[2] https://github.com/criticalstack/libevhtp/blob/1.2.13/evhtp.c#L2865
[3] https://github.com/freebsd/freebsd-ports/blob/branches/2018Q1/www/libevhtp/files/patch-evhtp.c
[4] https://github.com/haiwen/seafile-server/blob/v6.2.3-server/server/access-file.c
[5] https://github.com/haiwen/seafile-server/blob/v6.2.3-server/server/upload-file.c
[6] https://github.com/freebsd/freebsd-ports/blob/branches/2018Q1/net-mgmt/seafile-server/files/patch-server_access-file.c
Steps or code to reproduce the problem.
[7] https://reviews.freebsd.org/D13742
[8] curl -v "https://OBSCURED/seafhttp/files/c6629c8c-5324-OBSCURED-a9a46bf4aaa8/OBSCURED.rar"
CApath: none
< HTTP/2 404
< server: nginx
< date: Wed, 03 Jan 2018 22:09:47 GMT
< content-type: text/plain
< content-length: 0
<
Version
1.2.9 (works) --> 1.2.10 (Fails), 1.2.11 (Fails), 1.2.13 (Fails)
1.2.12 Also seems to be not work. Removing EV_WRITE on the line mentioned in [2] will cause everything to work again as it did in 1.2.9.
The text was updated successfully, but these errors were encountered: