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?

Comments

  • Nevermind, found it.

    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.
  • edited February 2017
    You suggestion is appreciated. I purposely left it out of the article for two reasons:
    • 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.
  • edited February 2017
    I also found out today that this AdditionalValues registry setting is not only required on the machine that runs the CGI, but also on the "server" machine. I tried to deploy my application from local development to 'company' development, but again I was missing headers.

    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.
  • I might not understand your configuration properly, but allow me to begin by stating that I think you are not following the recommended configuration that Revelation Software has specified. This subject is outside of the scope of the SRP HTTP Framework because we have no control over the way Revelation Software designed their OECGI product. Please refer to the 103-960 OECGI3.EXE Quick Start Guide.pdf document for further information. Having said that, if you are successfully getting requests then great. My opinion is to use what works. However, if you find that you have to update the Registry in two servers rather than one, then that is something you have to accept.

    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.
  • Side question for you. Since you are using WampServer, have you found that the HTTP_AUTHORIZATION header comes through or do you have to rely upon HTTP_X_AUTHORIZATION?
  • It's not coming through, so I switched to HTTP_X_AUTHORIZATION.

    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 :-)
  • It's not coming through, so I switched to HTTP_X_AUTHORIZATION.
    Pity. I thought perhaps this had been resolved with this implementation of Apache. That lack of proper support for the Authorization header is disappointing and I'm very surprised this project hasn't been updated to pass this through. I've tried various workarounds published by the Apache users but none ever seem to work.
    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 :-)
    I appreciate your desire to help others avoid potential pitfalls. For the record, I don't disagree with your design expectations. I just wanted to make sure it was understood that this issue is outside of our control.
  • Well I must admit that I haven't put a lot of research in this problem, because if HTTP_X_AUTHORIZATION works, that's fine with me :-). I did see some posts on stackoverflow that suggest that it may be caused by apache modules, and it can be bypassed with extra configuration. But if I need extra configuration anyways, I might as well use an other header ;-)
  • For the benefit of those who are unfamiliar with X-prefixed headers, this is just a way to submit custom, or non-standard, headers. So, the only reason X-Authorization works is simply because Apache ignores it and passes it through. For that matter, you could create any X-name you wanted and as long as your API code looks for this header then you can use it for anything.

    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.
Sign In or Register to comment.