You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the feature
Several HTTP headers are required while accessing the voyz/ibeam instance. The error messages are vague for some of these requirements.
All requests require a User-Agent header otherwise HTTP 403
Post requests require a Content-Length header otherwise HTTP 411 (this is apparent if you know the code. C# HttpClient.PostAsJsonAsync does not include this header however and was confusing to debug due to this however)
Explicitly mention that Apple Silicon is not supported. I Googled and found that mentioned in an issue thread but not in the documentation.
Expected interaction
Help end users interface when using custom-built interfaces
Possible implications
Users spend less time debugging
Additional context
This might be a feature request due to funkiness with Client Portal API gateway itself, but the IB documentation is not great so having those things here will also potentially create fewer issue threads popping up since you're just providing a proxy to a running instance of the client portal.
The text was updated successfully, but these errors were encountered:
Hi @demansou thanks for the request and for outlining some of your pain points 👍 Let me address them:
All requests require a User-Agent header otherwise HTTP 403
Post requests require a Content-Length header otherwise HTTP 411
I can see in the docs that for OAuth requests one does indeed need to set the User-Agent header, along with the others: https://www.interactivebrokers.com/campus/ibkr-api-page/cpapi-v1/#standard-headers However, for non-OAuth use, this sadly never gets mentioned. I think they go with the assumption that most clients set that automatically.
Would you be interested in contributing a WiKi Troubleshooting section on this? I never encountered these issues, hence I don't know the specifics here.
Explicitly mention that Apple Silicon is not supported.
I understand that it doesn't work for you. That being said, IBeam has been extended to ARM architecture by one of the users and now there are both 86x and ARM images available on Docker Hub. This leads me to believe that some users succeed in using it on ARM and by extension on Apple Silicon. Since I don't own any Apple devices I cannot verify this myself, but neither can I reliably show that it indeed doesn't work.
I feel that explicitly stating that it doesn't work should be backed by either some tests showing what exactly is preventing it from working, or from a large group of Apple Silicon users mentioning so, which hasn't been the case yet. I can see a contrary case, of a user who using Apple Silicon device was able to get it to work using the ARM build: #29 (comment) and another one of a user successfully using IBeam on a macOS: #197 (comment). I don't know the details of their deployment, but I think it shows that the statement you're suggesting may not necessarily be true for all cases.
That being said, I'm sorry that you couldn't get it to work on your end. Some troubleshooting falls outside of scope of what I know and where I could help. I'm glad you managed to get it deployed on the Raspberry PI though.
This might be a feature request due to funkiness with Client Portal API gateway itself
Indeed. Did you try contacting IBKR support requesting an update to their documentation regarding the HTTP headers?
Describe the feature
Several HTTP headers are required while accessing the voyz/ibeam instance. The error messages are vague for some of these requirements.
Expected interaction
Help end users interface when using custom-built interfaces
Possible implications
Users spend less time debugging
Additional context
This might be a feature request due to funkiness with Client Portal API gateway itself, but the IB documentation is not great so having those things here will also potentially create fewer issue threads popping up since you're just providing a proxy to a running instance of the client portal.
The text was updated successfully, but these errors were encountered: