400 Bad Request using httpRequester
Hi
I have a 400 Bad Request problem when I try to PUT my changes (I've just tried to update the title of an existing requirement).
PUT <the requirement URI>
showing 5 of 10
show 5 more comments
|
Accepted answer
You should include the quotes for the etag. In my testing, without them, you will get a 400 Bad Request error.
As to the authorization error, are you trying to GET/PUT directly to jts/storage? That would be a problem. There are additional steps you can take, in addition to requiring additional permissions, to be able to do this, but there's no reason you can't do this through the normal RM url. Something along the lines of: https://myServer:9443/rm/resources/_e-W5U530EeKIgKWYSSfl6w (or rdm if this was a server migrated from 2.x) Though I will add that a GET from RM will result in non-modifiable attributes being returned which must be removed from the content prior to using PUT. If you do not remove these, the PUT will fail, most likely with a 403 Forbidden, and list the problem attribute identifiers using a message of the form: CRRRS8660E Can not update system attribute: ... And yes, the URL for the project area is as you've shown it. helene højrup selected this answer as the correct answer
|
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.
Comments
hmmm... I didn't write the <meta data... > part - at least not on perpose
Sorry, I was looking at the wrong RM application server log. What it states in the end is:
Error 400: CRJZS5039E The ETag specified for If-Match is not legally formed (see http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html)
Typically when I want to perform a PUT, I perform the equivalent GET first to get the current state of various information (such as the artifact content and it's etag). Then I paste this over to my PUT request. Is that how you got the etag and can you show what the form of your etag value was?
Hi Stef
Thank you for your reply.
Yes I do the GET first to get the current state.
Form of my etag value?
This is what I get when I do the GET. Is that the answer to your question?
200 OK
Content-Type: application/rdf+xml
OSLC-Core-Version: 2.0
Etag: "_TsPdnx6MEeK-cKryrxtsYw"
Content-Encoding: gzip
Vary: Accept-Encoding
Content-Language: en-US
Transfer-Encoding: chunked
Date: Tue, 16 Apr 2013 16:38:11 GMT
Server: WebSphere Application Server/7.0
When I look into my licens I'm ticked off as a JazzUser. Do I have the rights to PUT? The reason why I'm asking is that when I look into the RM Application log, the following is also written:
Request
PUT https://myServer:9443/jts/storage/com.ibm.rdm.resources/_e-W5U530EeKIgKWYSSfl6w HTTP/1.1
X-Jazz-Owning-Context: myServer:9443/jts/process/project-areas/_OUfsouQmEeCDtNo-rCSbcA
If-Match: _e-p0Qp30EeKIgKWYSSfl6w
Content-Type: application/rdf+xml
Authorization: OAuth ...something more...
When I try to GET https://myServer:9443/jts/storage/com.ibm.rdm.resources/_e-W5U530EeKIgKWYSSfl6w
I get the following
Error 403: CRJZS5068E Storage area is restricted. The authorization key is required to access the resource: storage/com.ibm.rdm.resources/_e-W5U530EeKIgKWYSSfl6w
Yes. So when you set the headers for the PUT, are you providing that Etag value (including the quotes) on the If-Match?
It's also important to specify the net.jazz.jfs.owning-context, which is the full url of the project area which contains the resource.
I'm not including the quotes in the etag - and that is correct, right?
I willl try to take a look at the net.jazz.jfs.owning-context.
The URL for the project area that I find in the RMcatalog right? For me it looks something like:
https://myServer:9443/jts/process/project-areas/_OUfsouQmEeCDtNo-rCSbcA
When I now try to PUT I get authorization error, and could this be due to may JazzUser rights?
Haha :D It worked with the quotes around the etag!
I didn't have to put in the net.jazz.jfs.owning-context.
Thank you a lot Stef!
Be careful about the net.jazz.jfs.owning-context. The PUT will succeed without it, but it may end up moving the resource to another context (specifically the PUBLIC_CONTEXT) at which point your artifact will "disappear" from the project/folder. You may be ok in your example as I forget which scenarios can cause this, but it wouldn't hurt to perform a GET again to verify the context is still as expected.