How about replacing the $random_uuid with an MD5 (or stronger) digest of the message body? That would eliminate the undefined result of sending a message with the same message id but a a different body. (Undefined results can be opportunities for exploits.) --Omei Turnbull 20:21, 10 July 2007 (PDT)
- That wouldn't solve the problem, you would still be sending a message with the same message id if you sent two identical messages bodies. You would be guarantying a collision. It is really only an issue if two messages of the same ID are being processed at the same time. I think using $random_uuid is reasonable and in the event of a Message-ID collision or malformed Message-ID have the server return a 400. -- Strife Onizuka 00:01, 11 July 2007 (PDT)
- Heh, looks like Strife and I saw this at the same moment. :-) I guess if you digested the entire state of the message, including headers, receiving url, and sending url/host, then you're only ruling out the case where you do actually want to send two of the exact same message between the same two hosts at the exact same time and have both be processed as independent message. Thanks for the idea! Which Linden 00:06, 11 July 2007 (PDT)
- "If the client performs a GET to the message url prior to DELETE, the server must return the same body as the original response, including the X-Message-URL."
I think this may be an attack point, since it would require the server to cache the response body. There should also be a short timeout on the caching. This requirement makes it look like this protocol isn't something you want use with unauthorized clients. -- Strife Onizuka 00:18, 11 July 2007 (PDT)
- How does this differ from the explicit requirement that "the server must persist the response body or have a mechanism to idempotently generate the same response to the same request"? But yes, it seems likr the need to persist un-acknowledged response bodies for 15 days creates a big opportunity for a DDOS-type attack if reliable messages from unauthenticated clients are allowed.