When reading the proposed queuing scheme on rfc-gnutella (http://rfc-gnutella.sourceforge.net/...ella_queue.txt) it occured to me that when implemented this widely anyone could go around crawling through gnutella and direct a distributed denial of service attack on any server on the net.

Crawl gnutella and search for common files like "nude" or "Britney" and request some/all results with the new header;

GET /get/123/foobar.txt HTTP/1.0
Range: bytes=0-
User-Agent: Some Client 1.0
X-Host: 123.1.2.3:80

Where 123.1.2.3 is the (in this example web-) server you'd like to hit.


To prevent this you can;

a) Only allow a change of port.
AFAIK the outgoing and incomming IP address of any "normal" firewall is always the same. But you need to know which port is to be used for the callback.
X-Callback-port: 6346

b) Don't do callbacks
Keeping a socket open requires virtually no IP packets at all, so why not keep some of the queued sockets open?

Request from client
GET /get/123/foobar.txt HTTP/1.0
Range: bytes=0-
User-Agent: Some Client 1.0
X-Queue-Request

Response from server when immedeately queuing.
HTTP 100 OK
Server: Some Server 1.0
X-Queued: position=3; eta=42; ID={123432-45673-58787-65465465}
Server waits with transmission until a slot is available.

When there is no queue-slot available, it asks the client to retry.
HTTP 503 Server Busy
Server: Some Server 1.0
X-Queue-Retry: 600
X-Queued: position=8; eta=3600; ID={123432-45673-58787-65465465}
The client waits 10 minutes (600) and retries the request. The retry time can be estimated by the server as the eta for the first queue-slot (plus some)

Request from client when retrying
GET /get/123/foobar.txt HTTP/1.0
Range: bytes=0-
User-Agent: Some Client 1.0
X-Queue-Request: ID={123432-45673-58787-65465465}

c) ... (anyone?)


---

Although option a) is a _lot_ simpeler to implement, I personally don't like the idea of callbacks. It seems to me that if you want something, then come and get it.