Why doesn't Request implement Copy?

[bemyak]

I'm writing a small HTTP proxy, which gets a request, adds some headers and executes it. If the request fails, it adds different headers and retries.

Since sending the request consumes it, I'd like to copy() it in order to be able to send it the second time. This turns out to be surprisingly painful:

1. Request doesn't implement the Copy trait
2. Parts are not Copy as well
3. I can't even construct Parts myself, since they have a private field and are not Default
4. Most of the Parts fields are Copy, except for extensions, which is Option<Box<HashMap<_,_>>> so it can be made Copy, but isn't

Is there a reason to forbid such a use case, or am I the only one who stumbled upon it?

[davidpdrsn]

By Copy do you mean Clone? Copy implies a memcpy of the bytes, which won't work for many parts of the request.

Re extensions: HashMap is only Clone if the keys and values are, which won't work for extensions since the values are trait objects that don't implement Clone.

Request bodies are often streams which cannot be cloned either.

I agree that having cloneable requests would be nice, but there are lots of challenges to make it.

[bemyak]

Thank you for the quick answer. Yes, I meant Clone, sorry for the confusion.

Is there any real use case when something non-Clone is put into the extensions map? It is said to store extra data derived from the underlying protocol, so I don't expect anything outside the hyper ecosystem uses it, right?

[davidpdrsn]

Extensions are actually very useful outside of hyper. It's the only way for middleware for pass data around. We use it a bunch in axum and tower-http. So yes I would expect it to contain non-cloneable data.

[bemyak]

Got it. I'll get back to using tide then :)

[davidpdrsn]

Perhaps I'm misunderstanding but tide::Request doesn't implement Clone either.

http_types::Request (which I believe tide uses internally) removes the body and extensions when cloning. That can also be done with hyper's request type (actually http::Request). So really they have the same challenges but choose a different solution.