Skip to main content
A
Anonymous
August 3, 2016
Question

wrong status line "html" Leads REST API endpoint

  • August 3, 2016
  • 1 reply
  • 3550 views

Recently, we've been seeing HTTP "wrong status line" errors when hitting the Leads REST API endpoint. The status line is an expected line in HTTP responses (see section 6.1) that "[consists] of the protocol version followed by a numeric status code..." and looks something like this "HTTP/1.1 200 OK". Effectively, this is just the part of the "header" for an HTTP request. However we're seeing the error wrong status line \"<html>\".

Based on this response, we're guessing one of two things:

1. The expected response content is supposed to be JSON, but this is obviously HTML. This could mean that there's a maintenance HTML page put up instead of a specific "maintenance" JSON response. This usually shouldn't affect the HTTP response headers... but depending on how the configuration is set up for putting up this maintenance page, it could. Additionally supporting this "maintenance" page problem is that these errors happen almost universally around 04:34 UTC (which is 23:34 EST).

2. Potentially, there's a problem with the request we are sending, and the returned response doesn't handle it properly. This seems unlikely as we can see the raw request we are making and it is in line with the Docs for the Marketo Leads endpoint. Also, while the error occurs often, it is still intermittent. This means that its less likely that the request itself is the problem (but not impossible).

If we could have some Marketo developer attention into this issue that would be most welcome. Even if the problem is just maintenance, it will give us an answer and a course of action to resolve these issues.

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.

1 reply

Kenny_Elkington
Adobe Employee
Kenny_ElkingtonAdobe Employee
Adobe Employee
August 3, 2016

Do you have an example request/response where you're seeing this returned?

A
Anonymous
August 3, 2016

I think I may have found the problem. We specify both the fields we want and then the lead id(s) we wanted. We're using Ruby, and occasionally, instead of passing the filter values for the lead id (e.g. 2) we were sending the encoded Ruby hash like: %23%3CObject%3A0x000000144a9cc0%3E (which is #<Object:0x000000144a9cc0> when decoded)....

So the problem was on our end, but I guess the only thing that could be better is if the API returned a 400 (Bad Request) instead of what I guess is an error page in HTML. That's the only thing I could guess causes the problem, but I can't reproduce it. Doing just one request like:

/rest/v1/leads.json?filterType=id&filterValues=%23%3CObject%3A0x000000144a9cc0%3E

will produce a better and expected response of:

{

"requestId": "a795#156517c2ffd"

"success": false

"errors": {

     "code": "1003"

     "message": "Invalid id '#<Object:0x000000144a9cc0>' specified"

     }

}

But it might have something to do with the number of these hashes that are passed or the size of the GET request.

We only see this error when the GET request to the Leads input is VERY large (i.e. specifying 172 fields, and 250 lead ids*). So maybe it has to do with the length of the GET request? Normally we'd get a more useful error from HTTP when the the GET request is too long (the request wouldn't even be sent in that case).

* which were actually the aforementioned object hashes.

Kenny_Elkington
Adobe Employee
Kenny_ElkingtonAdobe Employee
Adobe Employee
August 3, 2016

You'd normally get a 414 if the request URI were too large (over 8k), so if you're getting a 200 and then the bad line, then it would not be that specifically.

Terms & ConditionsAccessibility statement

Loading footer...