• Replies 6 replies
  • Subscribers 18 subscribers
  • Views 1025 views
  • Users 0 members are here
Options
Related

Communication: any way to...

Talkabout
... get the response headers of a request?

Hi guys,

I have an application running that gets data from a server that is secured by a token. When firing a request the server responds with a 400 Bad Request but sends the token in one of its header. Is there a way with connect iq to get the returned headers?

Thanks!

Bye
  • You cannot access the response headers directly from ConnectIQ. If this is something you need, the current workaround is to write a pass-through service that forwards requests and repackages the response so that the headers are included in the response body.

    Travis
  • Hi Travis,

    thanks for the answer!

    Is this something that you could consider to add to the API? I think it makes sense for the developers to also access data from headers, as this is a common way to return information to the client without changing the response body. A third parameter in the callback as dictionary containing header names as keys and header values as values would be sufficient.

    Thanks!

    Bye
  • It may be useful, but due to compatibility concerns this change would not be quite as simple as you suggest. We can't just add parameters to the callback as existing apps expect to receive two parameters; passing three parameters to those callbacks would cause crashes. I'm not saying it can't (or won't) be done. I'm simply saying it isn't as simple as just adding an additional parameter.

    I'll file something for this and we'll see where it goes.
  • I'd be concerned this would add too much data to the payload transferred from GCM on the phone to the watch. The link speed is very slow (and the memory available to the receiving app quite small) and would rather the API response remain as small as possible.
  • I agree with mappicus, and especially with comm in a background process, you don't want the payload any bigger than needed With backgrounding, memory can already be tight.
  • I think it needs to be defined per request whether the app wants to receive the header data or not. What could also be a solution is to include the request type "HEAD", which is an http standard. Tha way the headers are the actual data. What would also be possible to reduce data is to add an option to the options hash that will define, which header values to return. I think there a plenty of options available, question is, which one is the best :)

    Bye