It's a nice idea, but if I understand this correctly[1], the predictable bytes are very early in the request, as early as the second byte, which is 'E' (for a request which starts with something like `GET / HTTP/1.1`). So moving the cookie headers might not make much of a difference.
EDIT: I think I might be wrong. Trying to read a little more, it seems like the first few bytes are the easiest to predict and then it gets harder... but with an HTTP request, the first few bytes are kinda known anyway (`GET / ...`), so this doesn't give much advantage to the attacker. Perhaps randomizing the position of the cookie header, or perhaps adding more NO-OP headers could help against this kind of attack after all?
I thought that post was saying "right now we can only get the first line, but as we learn more we expect to get more and more data out of the request header, including potentially cookies!"
[1]http://security.stackexchange.com/a/31873/7306
EDIT: I think I might be wrong. Trying to read a little more, it seems like the first few bytes are the easiest to predict and then it gets harder... but with an HTTP request, the first few bytes are kinda known anyway (`GET / ...`), so this doesn't give much advantage to the attacker. Perhaps randomizing the position of the cookie header, or perhaps adding more NO-OP headers could help against this kind of attack after all?