#ls2 (irc2p) | #ls2 I2P Protocol Development Discussion - Next Meeting Monday, October 9th 6:30 UTC

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 en.wikipedia.org/wiki/HTTP_persistent_connection

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