-
Notifications
You must be signed in to change notification settings - Fork 47
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Content-type is being set to application/x-www-form-urlencoded #9
Comments
Hi @bbultman, I believe we needed that header to workaround a bug in Splunk 6.3. Is this blocking you? If so, we're open to a pull request |
It's somewhat urgent, but I need to wait for approval (company needs to sign the contribution agreement, etc). I'll be fixing this today (as per your recommendation), and if possible I'll create a PR for the fix in the future. |
@bbultman That sounds like a plan. If needed, you can always fork and modify the library for a quick fix. I'll see about prioritizing the change internally |
@bbultman after digging through this today, it looks like this URL encoding is "forced" upon us by the request library we use under the hood. I'm looking into our options. edit: I've created a PR for request: request/request#2417 |
We've just released v0.9.2 with this fix. Give it a try! |
Hi there!
Just found an issue using this package.
Lib: Splunk-logging v0.9.1
OS: MacOS 10.11.6
Node: 6.4.0
Splunk: 6.5.0
We're using a node script to send JSON data to splunk, and it's been working fine. Now I've stumbled upon an issue where the text includes parentheses inside a string.
For example, this:
id:329,build:(id:164979)
becomes:
id:329,build:%28id:164979%29
(as seen inside splunk)
I've isolated the issue to splunk-logging/splunklogger.js line 435, row 47.
The content-type is set to application/x-www-form-urlencoded, even though the default options for the request module include
"json": true
I hope that line 435 can be removed entirely. It makes no sense to me -- both indirectly setting the content-type to json, and then explicitly setting it to x-www-form-urlencoded afterwards.
The text was updated successfully, but these errors were encountered: