[PDB-2621] PDB should return content type for errors Created: 2016/04/11  Updated: 2016/05/19  Resolved: 2016/05/09

Status: Closed
Project: PuppetDB
Component/s: None
Affects Version/s: PDB 2.3.8, PDB 4.0.0
Fix Version/s: PDB 4.0.3, PDB 4.1.0

Type: Bug Priority: Normal
Reporter: Wyatt Alt Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Template:
Story Points: 1

 Description   

Example:

[~/Documents/puppetdb] (master) $ curl -vvv -X GET http://localhost:8080/pdb/query/v4/nodes -d 'query=["~","certname","**"]'
*   Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 8080 (#0)
> GET /pdb/query/v4/nodes HTTP/1.1
> Host: localhost:8080
> User-Agent: curl/7.44.0
> Accept: */*
> Content-Length: 27
> Content-Type: application/x-www-form-urlencoded
>
* upload completely sent off: 27 out of 27 bytes
< HTTP/1.1 400 Bad Request
< Date: Mon, 11 Apr 2016 16:53:50 GMT
< Content-Length: 61
< Server: Jetty(9.2.10.v20150310)
<
* Connection #0 to host localhost left intact
ERROR: invalid regular expression: quantifier operand invalid[~/Documents/puppetdb] (master) $



 Comments   
Comment by Jonathan Newman [ 2016/04/11 ]

It should also specify Content-Type in the response.

Comment by Ken Barber [ 2016/04/11 ]

Okay, so the conversion of errors to JSON, is here: PDB-2318, and not returning JSON is not a bug per se. It sounds like the problem is just that we're for some reason dropping Content-Type.

Comment by Ken Barber [ 2016/04/11 ]

What version did this start happening Jonathan Newman / Steve Axthelm ...?

Comment by Jonathan Newman [ 2016/04/11 ]

Ken Barber We found it in PE 2016.1.1, and it doesn't happen in PE 2015.3.0. I haven't narrowed it down any more than that.

Comment by Steve Axthelm [ 2016/04/11 ]

Ken Barber, does not happen in 2015.3.3.

Comment by Ken Barber [ 2016/04/27 ]

Hmm, looks like to me this problem has existed since PDB 3.0.0, which means 2015.2.0 I believe. See here: https://gist.github.com/kbarber/4852a5f8c226fb86bfe976006c7b4ace

In fact, scratch that, this kind of thing has existed since 2.3.x or perhaps older: https://gist.github.com/kbarber/c815baf17226af9ef0f3b4f79025bd96

So my question to you both Steve Axthelm and Jonathan Newman, does this sound correct to you? Its contrary to what you've stated but it can be fixed all the same. What version do we need this fixed in? If there is a workaround in our middleware, I presume the fix doesn't need too much backporting. Happy to work with whatever you think is best. I'm thinking 4.0.x (pe 2016.1.x I guess) at the moment.

I'm just worried that if you think it was a regression like you state, then I'm looking at the wrong problem.

Comment by Ken Barber [ 2016/04/27 ]

Research: just wanted to confirm the default behaviour for HTTP/1.1, and it seems like if content-type is not specified it more or less defaults to application/octet-stream unless the client can figure it out automatically: https://www.w3.org/Protocols/rfc2616/rfc2616-sec7.html#sec7.2.1

Comment by Ken Barber [ 2016/04/27 ]

Jonathan Newman no worries, we can fix it. If we start returning content-type, will this break your work-around by any chance? Just want to be cautious.

Comment by Jonathan Newman [ 2016/04/27 ]

Ken Barber I don't think we have any concerns in that regard. The work-around should be good for both paths, and I have tests to validate.

Comment by Ken Barber [ 2016/04/27 ]

WIP PR is here: https://github.com/puppetlabs/puppetdb/pull/1943

Comment by Ryan Senior [ 2016/05/19 ]

Shipped with 4.1.0

Generated at Mon Sep 23 08:40:26 PDT 2019 using JIRA 7.7.1#77002-sha1:e75ca93d5574d9409c0630b81c894d9065296414.