orignal
not yet
orignal
only relays
orignal
but I have another question
orignal
do we support "keep-alive" in server tunnel?
orignal
HTTP tunnel
orignal
you can turn it on but I don't publish that cap yet
zzz
huh?
zzz
TCP keep alive locally?
Xeha
Not TCP, HTTP. search for "Connection: Keep-Alive"
Xeha
Its a HTTP 1.1 thing where you can define on the timeout (till connection gets closed) and how many subsequent request you can do over the already open connection
zzz
oh, ok, thanks for clarification
zzz
we don't support that
orignal
zzz basically if few request my come throug a stream
orignal
for now I assume only one request
orignal
but people complain
zzz
I tried to make it work in 2005
orignal
that subsequent request don't have X-I2P- tags
orignal
so how you handle subsequent requests?
zzz
it's really hard to do a proxy that gets it right
orignal
just close connection?
orignal
or drop?
zzz
we always respond with Connection: Close
orignal
so, you let first one pass trough add X-I2P headers
orignal
if more comes you close. right?
zzz
we always respond with Connection: Close, so the client side should never send another
orignal
when?
orignal
when you receive response from server and send back?
zzz
both the server side and client side, I think
orignal
I mean from HTTP server
zzz
also, we strip connection: keep-alive on the client side, so it never gets to the server
orignal
thanks. will do the same
orignal
how about socks proxy?
orignal
that what that guys do
orignal
they try it through socks proxy
zzz
it's possible it might end up with both a connection: close and a connection: keep-alive, not sure
zzz
haven't thought about all the combinations possible
zzz
the important thing is if the proxy doesn't support it, don't let keep-alive go through
zzz
so either support it or block it :)
orignal
but we should strip it out on server side
zzz
yeah, it's a good point, it looks like I only strip it on the client side
R4SAS
maybe replace, not strip?
orignal
but anyway even if you send Connection: Close
R4SAS
replace any "Connection" header with close
orignal
what you do if next request comes
zzz
right, you have to put in Connection: Close if you strip it
R4SAS
but really, I don't understand problem...
zzz
the proxy must know about keep-alive for it to work. I don't think it just magically works if you don't have code for it
orignal
R4SAS read 333.i2p
orignal
basically I just pass it through as is
orignal
in the current code
R4SAS
only if client using socks
zzz
ok have the client-side proxy code in front of me:
zzz
we replace all Connection: xxx headers with Connection: Close, EXCEPT Connection: Upgrade, we leave as-is
zzz
we also strip Keep-Alive: and Proxy-Connection: headers, don't remember what they do
orignal
I care more abuut server side
zzz
we also do the same thing on the client side in handling the response
zzz
now for the two directions on the server side:
zzz
found it, in the request, we also replace Connection: xxx with Connection: Close, except for Upgrade
orignal
good to know
orignal
will do the same
zzz
we don't do anything with the response on the server side
zzz
so, 3 out of 4 places, we force Connection: Close. That should be sufficient
zzz
of course, if you can code up a working proxy implementation, great
zzz
actually, what I worked on in 2005 was HTTP pipelining. It was hard and I gave up.
zzz
keep-alive is "HTTP Persistent Connections"
zzz
in 1.1, persistent connections is the default so you MUST put in a Connection: Close header if there's no connection header present if you want to force it off
zzz
thats why I said strip and add, not replace
orignal
but my question is
orignal
if there a malfunctioning client or advesary
orignal
that sends more requests even with Connection: Close
zzz
the server wouldn't expect it even if it got to the server
orignal
so you pass through
zzz
I don't think we even pass data through after the headers, except for POST and CONNECT
zzz
so it wouldn't get through my server-side proxy for GET or HEAD
orignal
so you don't pass HTTP header as it comes from I2P?
zzz
we do filtering/processing in all 4 places: client side request/response and server side request/response
zzz
each place has unique requirements
orignal
got it
orignal
I need to filter requests at server side
zzz
yeah we actually do quite a lot of processing of requests on the server side
orignal
thanks
orignal
need to take care
orignal
I filter responses but not requests
zzz
throttling, blocking, spoof prevention, x-i2p-gzip preference, removing internal i2p headers, inproxy detection, user-agent blocking, putting in the desthash headers, ...
zzz
fixing up the Host header, canonicalizing the headers, ...
zzz
and a lot of timers and counters to prevent slowloris attacks and other ddos stuff
orignal
I only add desthashes
zzz
yeah that's another place you want to strip and then add, to prevent spoofing
zzz
because you don't know what the server does if there's two identical headers
orignal
I know
orignal
time to fix it