Getting Data In

HTTP Event Collector returns Bad Request - what is wrong with my event?

Contributor

While posting a request to Splunk via HEC, I get the response as {"text":"No data","code":5} and when I enable version on the curl http request, I get a 400 Bad Request , what is wrong with my event?

curl -k -v https://my-domain:8088/services/collector/event -H "Authorization: Splunk E671602E-0E02-40ED-AADB-FE674F338CF6" -d '{"host”:”some host”,”index":"testing","sourcetype”:”email”,”time":"2016/11/11 22:26:50","source”:”project_eagle”,”event":"{\"subscribed_source\":\"WEB\",\"subscribed_flag\":\"Y\",\"email_type\":\"CUSTOMER\",\"last_name\”:\”Raj\”,\”email_subtype\":\"SUBSCRIBER\",\"email_address\":null,\"product_id\”:\”100\”,\”templateVersion\":null,\"first_name\":\"MARGUERITE\",\"last_sub_change_datetime\":\"2016/11/11 22:26:50\"}"}'

Path Finder

This error 5 means "no data". Therefore 400 is returned. Payload has been rejected.

Watch out for invalid quotes. Test your json with an online syntax checker.

eg. Mix of quote types ("”). That is, regular " open quote but irregular 99 closure quote.
eg. Extra quotes. The third " below appears problematic.

"event":
"{
    "subscribed_source":"WEB",

@jkat54 asked for the payload with CORRECTED quotes:

{
"host":"some host",
"index": "testing",
"sourcetype":"email",
"time": "2016/11/11 22:26:50",
"source":"projecteagle",
"event":
{
"subscribed
source":"WEB",
"subscribedflag":"Y",
"email
type":"CUSTOMER",
"lastname":"Raj",
"email
subtype":"SUBSCRIBER",
"emailaddress":null,
"product
id":"100",
"templateVersion":null,
"firstname":"MARGUERITE",
"last
subchangedatetime":"2016/11/11 22:26:50"
}
}

0 Karma

Explorer

My problem was I had enabled SSL.

0 Karma

Contributor

I figured the issue seems to be with date/time format used in "time" field.

As per - http://dev.splunk.com/view/event-collector/SP-CAAAE6P default time format is long millisecond from epoch. Removing the component, helped me send the events to splunk.

I am wondering what are the other supported formats along with long milliseconds ?

SplunkTrust
SplunkTrust

So can you paste your new event that has the corrected quotes?

0 Karma

SplunkTrust
SplunkTrust

My apologies, I thought this was a comment. i still don't understand what you did. Did you remove the timestamp from the events?

0 Karma

Explorer

Removing timestamp worked for me , but why splunk does not accept its default time format is really something some has to find:

this what it says about time:

"time" The event time. The default time format is epoch time format, in the format .. For example, 1433188255.500 indicates 1433188255 seconds and 500 milliseconds after epoch, or Monday, June 1, 2015, at 7:50:55 PM GMT.

it should have worked, but why it does not work?, Is it worth using SplunkCloud support for programming questions?

0 Karma

Contributor

Not sure, why this was moved to a comment section, my issues is resolved, with my own answer (at least for now), and outline answer has nothing to do with it. Please move it back to its won answer, so I can mark it complete. Thanks!

0 Karma

SplunkTrust
SplunkTrust

You have "magic quotes" / "slanted quotes" in there. Convert everything to straight quotes and it should work.

0 Karma

SplunkTrust
SplunkTrust

So can you paste your new event that fails but has the corrected quotes?

0 Karma

SplunkTrust
SplunkTrust

Did you test with straight quotes?

"product_id\”

The above won't work because the quotes on left don't match the quotes on right.

" does not equal ”

Time shouldn't matter. Splunk will recognize all sorts of timestamps out of the box. Especially the one you have mentioned. However it should be at the beginning of your event unless you're setting a large MAXTIMESTAMPLOOKAHEAD on your sourcetype.

Contributor

I did check on the quotes, and that doesn't seem to be the issue. My event itself doesn't have a time stamp, and setting it into the protocol with time attributes in the json. I don't think sequence of where that time field is appearing is causing issues..because I have several sourcetype that follow the same convention. And they all do work. Only difference I could spot so far is just the difference in time/date format.

0 Karma