There are two problems with client generated ID's, and the main one is that you can't guarantee that the cancellation message will go to the same server as the original invocation. With my current design the initial request will send back a JSESSIONID that allows the cancel request to be targeted at the correct server (of course if we already have affinity then this is not a problem, but we can't guarantee that).
The other problem is that there is no easy way to guarantee there will not be conflicts, although I guess you could send back a 409 and force the client to retry with a new cancellation id if a conflict happens. You can't really tie this to IP because it may be behind a load balancer, and something like a GUID may be expensive to generate for every invocation.
With the 1xx approach I am worried that not all load balancers/proxies will properly support it. As this is not really used outside of 'Expect: 100-continue' I would be surprised if this works correctly without problems, even though it is valid according to the spec.
Another potentially yucky way to do this would be to have the client use chunked encoding and keep the request open, allowing it to send some kind of cancellation token at any time. This feels really hacky though.
Basically all the options suck, the one I put in the doc was that one that I thought sucked the least when dealing with load balancers.