Cometd Client Headers

[leenelc]

How do I view the headers being sent in a cometdClient object? More specifically, the value of the headers that have not been pre-configured... for example the Bayeux Browser cookie header

[sbordet]

This is not currently possible. Can you please specify why you want to do that? The more information we have, the more we can implement the feature in the correct way.

Also, reading HTTP response headers ties you to the HTTP transport. What if you want to use WebSocket?

[leenelc]

For the purpose of the application I am building, I am going to be using the HTTP transport only.

When you say tied to the HTTP transport, does this mean that if I generate multiple cometdClients the Bayeux Browser cookie is to remain the same throughout all?

The reason I want to maintain the Bayeux Browser cookie is to emulate a publish using HTTP rather than saving the cometd client object itself.

[sbordet]

When you say tied to the HTTP transport, does this mean that if I generate multiple cometdClients the Bayeux Browser cookie is to remain the same throughout all?

No, I am saying that if you use WebSocket in the future, your code will not work because there are no HTTP response headers.

The reason I want to maintain the Bayeux Browser cookie is to emulate a publish using HTTP rather than saving the cometd client object itself.

Why? I ask because maybe you want to do something on your own using raw HTTP that CometD can do already.

[leenelc]

The application I'm building requires that I persist multiple cometd connections with the server. However, I would rather not store the entirety of the cometd client object I am creating (this is to send publish requests using the same session) The workaround I have found is to save the client_id, the nextMessageId and the bayeux browser cookie and send an HTTP request accordingly.

[sbordet]

The application I'm building requires that I persist multiple cometd connections with the server.

This is not necessary in almost all cases. HTTP is a stateless protocol, so you don't strictly need persistent connections (although they are much more efficient).

I would rather not store the entirety of the cometd client object I am creating (this is to send publish requests using the same session)

What is the problem with storing the CometD client object?

The workaround I have found is to save the client_id, the nextMessageId and the bayeux browser cookie and send an HTTP request accordingly.

It won't work unless for a very short period of time. The server expects the client to send periodic heartbeats, otherwise it will declare the client dead and remove the session.

I feel you are going in the wrong direction based on wrong assumptions of how CometD and HTTP work.

So far you have explained your "solution" ("persist" connections, get rid of the CometD object, do raw CometD publishes by yourself), but you have not explained what is the problem yet and why you have decided to take all those uncommon "solutions".

I would recommend that you build your system using entirely the CometD APIs without worrying about "persisting" connections, storing or not the CometD object, etc. When you have the system working, you can look at whether there is any problem.

[sbordet]

No further activity, closing.