Welcome to the SRP Forum! Please refer to the SRP Forum FAQ post if you have any questions regarding how the forum works.
Missing HTTP Request headers
I am using wamp 3.0.6 for local development. It seems that my http headers are not coming through. I do see the headers accept, content-type, user-agent, accept-encoding and accept-language. But all other headers are missing.
Any suggestions?
Any suggestions?
Comments
I think it's usefull though to add HTTP_X_AUTHORIZATION to the wiki Registry Configuration article. The code is prepared for this header, but it isn't accepted in this configuration.
- Less importantly - It might not be easily seen since the format of that part of the article doesn't allow for word-wrapping.
- More importantly - HTTP_X_AUTHORIZATION is a work around to web servers that do not pass through the HTTP_AUTHORIZATION header. As such, it is a unique situation and I did not want to tailor an article for a specific use case even though the product supports HTTP_X_AUTHORIZATION internally.
What might be better is another article (perhaps a blog article) that explains the AdditionalValues registry value better and how this is used by the OECGI. I could then introduce HTTP_X_AUTHORIZATION as an example of why someone might want to update this value.After a lot of debugging and testing I found out that in HTTP_SERVICES the registry key is read to find the "AdditionalValues". This construction is weird in a few ways.
1) In our case the web server is running on a different machine. So OECGI4.exe is the client that connects to the Open Insight Server. I didn't expect I needed to have configuration options for the client on my server machine.
2) The Authorization header (not the X-Authorization) is kind of mandatory, since it's used in HTTP_AUTHENTICATION_SERVICES. So why isn't this header being set by default like User-Agent, Content-Type, etc. This way the HTTP Framework authentication is broken 'out of the box' if your webserver isn't running on the same machine as the Open Engine.
Imho it would make more sense to add this setting to the SRP_HTTP_FRAMEWORK_SETUP record in SYSENV. That way it doesn't matter who connects; this authorization code will always work in the same way.
Regarding your suggestion that the Authorization header be set up like some of the other headers, this too is something outside of our control. The Request array that the OECGI passes into the code that we have control over (i.e., HTTP_MCP and onward), is configured by Revelation Software. They could extend this array and have done so in the past. So you may want to submit a request to them. In the meantime, all we can do is update the AdditionalValues registry value when we want other headers to be passed through.
You were right; I didn't read that quick start guide, so I understand now why this registry approach was implemented. But from my point of view I still think it would make more sense to try and extract these authorisation headers by default. Just to make sure there is one less point of failure. If the header isn't there, the value simply could have been empty, or it could be skipped at all.
Anyways, I understand it's impossible to support all setups in the world. Just wanted to share in case other people are on the same path as we are :-)
When we began to notice that Apache applications were absorbing the Authorization header, we resorted to X-Authorization to keep with the spirit of the original header. It also appears to be what other Apache developers are using.
From our own research, it appears that Apache takes in the Authorization header and attempts to implement HTTP Basic authentication using older methods (i.e., server credentials and plain text files). Thus, it assumes responsibility for the authorization and opts not to pass it onward.