@reitermarkus can you check CI failures?

Also I am not sure if the updated Cargo.lock file is required here, remove it if its not relevant with this changes.

Added #[cfg(feature = "websocket")] for the added parts and removed the Cargo.lock changes.

Added a RequestModifierFn type alias to fix the complex type warning.

@reitermarkus

Do you have any specific reason you chose to go with mqtt_options.set_request_modifier(Fn(http::Request<()>)) instead of just passing in a fully formed request with something like mqtt_options.set_request(http::Request)?

You could modify the request later (for re-connections etc.) via eventloop.mqttoptions.set_request(updated_req). This seems much simpler to me. Unless there's a use case I missed which can't be serviced like this?

Well, I only need to set the auth/signature headers, so I don't want to also have to set all MQTT protocol-specific headers.

Also, the AWS ProvideCredentials trait may be implemented in a such way that credentials are automatically refreshed, so no additional changes would be necessary when reconnecting.

@reitermarkus

Well, I only need to set the auth/signature headers, so I don't want to also have to set all MQTT protocol-specific headers.

Yeah, I meant doing it such that rumqttc would still add the required missing headers to the, otherwise "fully formed", user supplied request. Now that I think of it, it'll be even better to just let the user pass in any additional headers that rumqttc then adds to the request itself.

Also, the AWS ProvideCredentials trait may be implemented in a such way that credentials are automatically refreshed, so no additional changes would be necessary when reconnecting.

This one is a slight advantage. But it'll still be possible to do this with .set_headers,just that you would have to manually update it if/when needed for re-connections.

I see the niceties of this closure style API but for rumqttc at the moment passing in additional headers would be simpler and more in line with how rest of the API works (eg see the manual acks examples).

That seems very unergonomic and unintuitive to use. I'd have to create an empty request with the URL I already passed to MqttOptions::new.

That seems very unergonomic and unintuitive to use. I'd have to create an empty request with the URL I already passed to MqttOptions::new.

@reitermarkus Agreed, Iike I said

Now that I think of it, it'll be even better to just let the user pass in any additional headers that rumqttc then adds to the request itself.

The better way to do it would be to just let the user set any additional headers they want to be sent along via an API like mqttoptions.set_ws_headers(headers: http::header::map::HeaderMap)

To get the headers I would still have to create a request, since signing is done on a fully formed request. There is no way to only get signature headers without a request in the first place.

To get the headers I would still have to create a request, since signing is done on a fully formed request. There is no way to only get signature headers without a request in the first place.

@reitermarkus Makes sense. That's the sort of stuff I was looking for when I asked:

Unless there's a use case I missed which can't be serviced like this?

Sorry for the delay and thanks for your contribution 🚀

@yatinmaan, could you release a new version with this included? Thanks.

@yatinmaan, could you release a new version with this included? Thanks.

@swanandx ^^

thnx for the ping @yatinmaan ! We will release rumqttc this week @reitermarkus 💯

update: rumqttc v0.23.0 is released, which includes this change!