After running ipa-server-install, /var/log/pki/pki-tomcat/localhost_access_log.2015-*.txt contains
10.16.96.106 - ipara [27/Aug/2015:04:50:19 -0400] "POST /ca/rest/profiles/raw HTTP/1.1" 400 148
Steps to Reproduce:
1. Run ipa-server-install. 2. Check /var/log/pki/pki-tomcat/localhost_access_log.2015-*.txt.
Actual results:
10.16.96.106 - - [27/Aug/2015:04:48:43 -0400] "GET /ca/admin/ca/getStatus HTTP/1.1" 200 167 10.16.96.106 - - [27/Aug/2015:04:50:17 -0400] "GET /ca/admin/ca/getStatus HTTP/1.1" 200 167 10.16.96.106 - ipara [27/Aug/2015:04:50:18 -0400] "GET /ca/rest/account/login HTTP/1.1" 200 205 10.16.96.106 - ipara [27/Aug/2015:04:50:18 -0400] "POST /ca/rest/profiles/raw HTTP/1.1" 201 7333 10.16.96.106 - ipara [27/Aug/2015:04:50:18 -0400] "POST /ca/rest/profiles/IECUserRoles?action=enable HTTP/1.1" 204 - 10.16.96.106 - ipara [27/Aug/2015:04:50:19 -0400] "GET /ca/rest/account/logout HTTP/1.1" 204 - 10.16.96.106 - ipara [27/Aug/2015:04:50:19 -0400] "GET /ca/rest/account/login HTTP/1.1" 200 205 10.16.96.106 - ipara [27/Aug/2015:04:50:19 -0400] "POST /ca/rest/profiles/raw HTTP/1.1" 400 148 10.16.96.106 - ipara [27/Aug/2015:04:50:20 -0400] "POST /ca/rest/profiles/caIPAserviceCert?action=disable HTTP/1.1" 204 - 10.16.96.106 - ipara [27/Aug/2015:04:50:20 -0400] "DELETE /ca/rest/profiles/caIPAserviceCert HTTP/1.1" 204 - 10.16.96.106 - ipara [27/Aug/2015:04:50:20 -0400] "POST /ca/rest/profiles/raw HTTP/1.1" 201 7008 10.16.96.106 - ipara [27/Aug/2015:04:50:20 -0400] "POST /ca/rest/profiles/caIPAserviceCert?action=enable HTTP/1.1" 204 - 10.16.96.106 - ipara [27/Aug/2015:04:50:20 -0400] "GET /ca/rest/account/logout HTTP/1.1" 204 - 10.16.96.106 - - [27/Aug/2015:04:50:21 -0400] "POST /ca/ee/ca/profileSubmitSSLClient HTTP/1.1" 200 1695 10.16.96.106 - - [27/Aug/2015:04:50:38 -0400] "GET /ca/admin/ca/getStatus HTTP/1.1" 200 167 10.16.96.106 - - [27/Aug/2015:04:50:43 -0400] "POST /ca/ee/ca/profileSubmitSSLClient HTTP/1.1" 200 1695 10.16.96.106 - - [27/Aug/2015:04:50:44 -0400] "POST /ca/ee/ca/profileSubmitSSLClient HTTP/1.1" 200 1292 10.16.96.106 - - [27/Aug/2015:04:52:20 -0400] "GET /ca/admin/ca/getStatus HTTP/1.1" 200 167 10.16.96.106 - - [27/Aug/2015:04:53:05 -0400] "GET /ca/admin/ca/getStatus HTTP/1.1" 200 167
Expected results:
No status 400 there.
Additional info:
During normal course of installation, we shouldn't be producing 4xx and 5xx statuses.
As I understand this issue, there are two issues here:
IPA attempts to add a profile when one already exists. If this is so, then an IPA ticket should be opened to check for the existence of the profile first.
There is a question as to whether the server should return 400 (as it currently does) or 409 (conflict) when a profile already exists and you are trying to add one.
After talking with elmiko (our guy on the Openstack API committee), I'm inclined to agree with 409. The rfc says :
The 409 (Conflict) status code indicates that the request could not be completed due to a conflict with the current state of the target resource. This code is used in situations where the user might be able to resolve the conflict and resubmit the request. The server SHOULD generate a payload that includes enough information for a user to recognize the source of the conflict.
That is, the client can do something to fix this - remove the existing resource - for instance. He does not necessarily say that he can fix it with the same request - and in fact, it does not imply that the request itself is invalid (which in this case, it isn't).
400 appears to be client error. ie. the request itself is invalid. The RFC says:
The 400 (Bad Request) status code indicates that the server cannot or will not process the request due to something that is perceived to be a client error (e.g., malformed request syntax, invalid request message framing, or deceptive request routing).
So lets change to 409, and open a ticket for IPA to add existence checking.
fixed in master 27a38daf9840e4fd9bc031daf25024806d05e943
Metadata Update from @jpazdziora: - Issue assigned to ftweedal - Issue set to the milestone: 10.3.0
Dogtag PKI is moving from Pagure issues to GitHub issues. This means that existing or new issues will be reported and tracked through Dogtag PKI's GitHub Issue tracker.
This issue has been cloned to GitHub and is available here: https://github.com/dogtagpki/pki/issues/2286
If you want to receive further updates on the issue, please navigate to the GitHub issue and click on Subscribe button.
Subscribe
Thank you for understanding, and we apologize for any inconvenience.
Login to comment on this ticket.