You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently tiny-http may not support CONNECT method well. After the first CONNECT event occurs, all subsequent DATA from peer host should not be treated as Request anymore, so tiny-http should expose corresponding socket(or reader/writer) to the user and remove this connection from contentiously receiving loop thread.
two options I've thought:
changing the interface: incoming_requests() returns new Message type:
and in receiving loop check the message type first, if is CONNECT then keeps track of this connection and doesn't do anymore Reqeust parsing on any subsequent packets.
let mut is_normal_req = false;
for rq in client {
if is_normal_req {
if(rq.method() == Method::CONNECT) {
is_normal_req = false;
}
todo!(); // push `rq` to queue `messages`
} else {
todo!(); // directly return DATA(Vec<u8>)
}
}
changing the CONNECT related data, when CONNECT arrives, returns CONNECTRequest with the underlying sock(or reader/writer) to users, and break the receiving loop thread.
for rq in client {
let is_normal_req = rq.method == Method::CONNECT;
todo!(); // push `rq` to queue `messages`, and attach sock(or reader/writer) to this Reqeust Message if is `CONNECT`
if is_normal_req {
break;
}
}
now users can reuse returned sock(or reader/writer) to construct new TCP tunnel.
any suggestions?
The text was updated successfully, but these errors were encountered:
Currently tiny-http may not support
CONNECT
method well. After the firstCONNECT
event occurs, all subsequentDATA
from peer host should not be treated asRequest
anymore, so tiny-http should expose corresponding socket(or reader/writer) to the user and remove this connection from contentiously receiving loop thread.two options I've thought:
changing the interface:
incoming_requests()
returns new Message type:to
and in receiving loop check the message type first, if is
CONNECT
then keeps track of this connection and doesn't do anymoreReqeust
parsing on any subsequent packets.changing the
CONNECT
related data, whenCONNECT
arrives, returnsCONNECT
Request
with the underlying sock(or reader/writer) to users, and break the receiving loop thread.now users can reuse returned sock(or reader/writer) to construct new TCP tunnel.
any suggestions?
The text was updated successfully, but these errors were encountered: