champo / duta Goto Github PK

If an outbound connection fails to resolve, the proxy wont take it nicely.

To avoid excesive allocation & garbage collection

Must support both file based storage and memory based storage

When trying to request http://blog.dwolla.com/ach-goes-real-time-with-fisync-free-for-banks-and-credit-unions/ through the proxy the response is invalid.

Valid request with curl (without dUta):

jpcivile@whitey ~ $ curl  -vvv http://blog.dwolla.com/ach-goes-real-time-with-fisync-free-for-banks-and-credit-unions/ > /dev/null
* About to connect() to blog.dwolla.com port 80 (#0)
*   Trying 199.79.48.49...   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0connected
> GET /ach-goes-real-time-with-fisync-free-for-banks-and-credit-unions/ HTTP/1.1
> User-Agent: curl/7.22.0 (x86_64-apple-darwin10.8.0) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.6 libidn/1.22
> Host: blog.dwolla.com
> Accept: */*
> 
< HTTP/1.1 200 OK
< Date: Tue, 08 May 2012 19:05:28 GMT
< Server: Apache
< Vary: Accept-Encoding,Cookie
< Cache-Control: max-age=3, must-revalidate
< WP-Super-Cache: Served supercache file from PHP
< Transfer-Encoding: chunked
< Content-Type: text/html; charset=UTF-8
< 
{ [data not shown]
100 32111    0 32111    0     0  11077      0 --:--:--  0:00:02 --:--:-- 12402
* Connection #0 to host blog.dwolla.com left intact
* Closing connection #0

Invalid response (with dUta):

jpcivile@whitey ~ $ curl -x localhost:9999 -vvv http://blog.dwolla.com/ach-goes-real-time-with-fisync-free-for-banks-and-credit-unions/
* About to connect() to proxy localhost port 9999 (#0)
*   Trying 127.0.0.1... connected
> GET http://blog.dwolla.com/ach-goes-real-time-with-fisync-free-for-banks-and-credit-unions/ HTTP/1.1
> User-Agent: curl/7.22.0 (x86_64-apple-darwin10.8.0) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.6 libidn/1.22
> Host: blog.dwolla.com
> Accept: */*
> Proxy-Connection: Keep-Alive
> 
< HTTP/1.1 301 Moved Permanently
< Date: Tue, 08 May 2012 19:05:41 GMT
< Server: Apache
< Set-Cookie: PHPSESSID=mucunfles8q3vr25qh09m8kjr5; path=/
< Expires: Wed, 11 Jan 1984 05:00:00 GMT
< Cache-Control: no-cache, must-revalidate, max-age=0
< Pragma: no-cache
< Vary: Cookie,Accept-Encoding
< X-Pingback: http://blog.dwolla.com/xmlrpc.php
< Last-Modified: Tue, 08 May 2012 19:05:41 GMT
< Location: http://blog.dwolla.comhttp/blog.dwolla.com/ach-goes-real-time-with-fisync-free-for-banks-and-credit-unions/
< Connection: close
< Transfer-Encoding: chunked
< Content-Type: text/html; charset=UTF-8
< 
* Closing connection #0

Right now if a request aborts the associated data buffers may leak, for example if a FileDataBuffer is being used.

The dude be evil.

Otherwise, a race condition may ocurr

The append event won't be used by anyone (except file size filter), and the FilterChain already needs to keep track of the size. So it makes sense to switch append for bytes transfered

I just got a NPE due to #24, and that exception killed the reactor thread it was running on.

from RequestChannelHandler.read and Operation.addResponseData to a single place, probably in Operation or FilterChain

If a message is too big or of unknown size, we should a FileChannel to read from the SocketChannel. Handy methods like transferTo and transferFrom should make this rather painless.

Support monitoring the proxy's statistics from the admin server

See: TRACE, OPTIONS, CONNECT

Right now byte traffic is not tracked correctly

When they are not know to accept multiple values

the label-name of a message header is case insensitive, so when pasting headers with the same label-name, this should be taken into account.. notice that this implies that if the original label-names are to be saved, there could be more than one variation (ej: Date, date, etc)

Add the logic to the admin filter to manage filters

When reading the end of a message, if the start of the next one is read in the same channel read operation, the second message data will be added to the first message. The correct behaviour would be to create a new message with the data that doesn't belong to the first one.

This isn't a problem if pipelining isnt enabled.

Setup a special filter that will handle adminstrative tasks

Add a timer that cleans unused connections every once in a while

If the header is bigger that the size of the first buffer, it wont be parsed (the proxy'll probably go haywire)

Let's be honest, there's no time to handle the concurrency of having ClientHandler and ServerHandler on different threads.

That.

That, and HTTP1.0 transfers dont really get along.

Must support both parsing Content-Length header and chunked encodings

Right now the response parser expects to read the whole responde header in the first read. Clearly, that's not smart. A logic closer to what RequestChannelHandler does would be awesome.

In header fields Content-Encoding and Transfer-Encoding (as a comma separated list)

If a request takes too long to complete, kill'im