It's all about the answers!

Ask a question

OSLC Requirement Update results with status 412 Precondition Failed

James Antoine (1823) | asked May 01 '14, 2:07 p.m.

I am developing an OSLC interface to exchange requirements between my product and DOORS.  I can import requirements from DOORS; I can create Requirements in DOORS.

However, when I try to update with:

HttpResponseMessage response = UpdateResource(requirementUrl, requirement, OslcMediaType.APPLICATION_RDF_XML, OslcMediaType.APPLICATION_RDF_XML, etag);

I get a HTTP status of 412. 

As a debugging step I perform:

1.Requirement r = Get Resource ()

2. r. Get ETag

3. Update Resource (r)

4. The HTTP status code is 412. ( this seems to indicate that the Requirement is DOORS was updated between the GET and the Update. but I am the only user and I issue the put immediately after the GET)

I noticed a similar question from 2012 but there is no answer to that question.

All the documentation that I have reviewed seem to indicate the procedure is correct but there must be some implementation issue that I do not understand, I am using DOORS 9.5.2. 



8 answers

permanent link
Benjamin Silverman (4.1k610) | answered May 01 '14, 2:11 p.m.
Do you have a stack trace in your rm.log?  You can usually work around this by setting = true (from rm/rmadmin -> Advanced Properties), or setting it in the rm and restarting the server.  In the case you enable it from rm/rmadmin, you wont need to restart.  But an error log would be useful if that doesn't help.

permanent link
James Antoine (1823) | answered May 02 '14, 8:48 a.m.

Benjamin -

Thanks for taking my question and speedy response.

A couple of notes:

1. I am using DOORS 9.5 and I am not aware of an option for configuring AllowOSLCPutWithOutIfMatchHeader. I will research this.

2. My Update Resource request includes the If-Match header (Etag), so would that configuration still be useful?

permanent link
Sudarshan Rao (1963) | answered May 02 '14, 10:20 a.m.
 I think Ben's comment was based on DOORS Next perspective. He'll correct me if I'm wrong in assuming this..

When you say:
"4. The HTTP status code is 412. ( this seems to indicate that the Requirement is DOORS was updated between the GET and the Update. but I am the only user and I issue the put immediately after the GET)"

How are you inferring requirement in DOORS was updated? If you do a GET again on the resource, do you get a different Etag than what you obtained in your previous GET?
Other than that, just ensure the If-Match header is correctly formed with Etag value in your PUT..

What content are you using to update - are you re-using the response of GET? That's the best way to use.. 
What resource are you trying to update - object? And it fails on all objects?

permanent link
James Antoine (1823) | answered May 02 '14, 10:42 a.m.

Sudarshan -


Right,  I will have to get the exact message, but while debugging the response included a message indicating that the resource on DOORS had "changed".  

But my issue could very well be as you suggest that my request is not well formatted with respect to the If-Match header and the ETag.   I will take a look at that.   I have looked at both the request and response in Fiddler and the request seems to be "Ok" when I compare it to what I see in come OSLC sample request messages.



permanent link
James Antoine (1823) | answered May 02 '14, 2:06 p.m.

Sudarshan -

Not sure if this is useful but thought I would post a sample request/response:


PUT http://jantoine-xps:8080/dwa/rm/urn:rational::1-52e825ce3c6a2b0e-O-123-000000a2 HTTP/1.1

Accept: application/rdf+xml

OSLC-Core-Version: 2.0

If-Match: "e1d8db24aae54cd8a41e3ceda5ada737"

Authorization: OAuth oauth_version="1.0",oauth_nonce="v310Z5az",oauth_timestamp="1399053706",oauth_signature_method="HMAC-SHA1",oauth_consumer_key="genesys",oauth_token="1ca2f686-ed58-4773-b126-30fc0812459b",oauth_signature="hArzQp8Y4EUUlDQm6E4mWbvaGdk%3D"

Content-Type: application/rdf+xml

Host: jantoine-xps:8080

Cookie: JSESSIONID=34B235B1AB17424D0CC53ACC5B19E932

Content-Length: 4556

Expect: 100-continue

Connection: Keep-Alive

<?xml version="1.0" encoding="utf-8"?>

<rdf:RDF xmlns:rdfs="" xmlns:xsd="" xmlns:ns0="" xmlns:rdf="">

<ns0:Requirement rdf:about="http://jantoine-xps:8080/dwa/rm/urn:rational::1-52e825ce3c6a2b0e-O-123-000000a2">

<ns1:attrDef-10 xmlns:ns1="http://jantoine-xps:8080/dwa/rm/urn:rational::1-52e825ce3c6a2b0e-M-000000a2/types/" rdf:resource="http://jantoine-xps:8080/dwa/rm/urn:rational::1-52e825ce3c6a2b0e-M-000000a2/types/attrDef-10#1" />

<ns2:attrDef-13 xmlns:ns2="http://jantoine-xps:8080/dwa/rm/urn:rational::1-52e825ce3c6a2b0e-M-000000a2/types/" rdf:datatype="">Requirement Short Text</ns2:attrDef-13>

<ns3:attrDef-4 xmlns:ns3="http://jantoine-xps:8080/dwa/rm/urn:rational::1-52e825ce3c6a2b0e-M-000000a2/types/" rdf:datatype="">Administrator</ns3:attrDef-4>

<ns4:attrDef-5 xmlns:ns4="http://jantoine-xps:8080/dwa/rm/urn:rational::1-52e825ce3c6a2b0e-M-000000a2/types/" rdf:datatype="">2014-04-28</ns4:attrDef-5>

<ns5:attrDef-6 xmlns:ns5="http://jantoine-xps:8080/dwa/rm/urn:rational::1-52e825ce3c6a2b0e-M-000000a2/types/" rdf:datatype="">Administrator</ns5:attrDef-6>

<ns6:attrDef-7 xmlns:ns6="http://jantoine-xps:8080/dwa/rm/urn:rational::1-52e825ce3c6a2b0e-M-000000a2/types/" rdf:datatype="">2014-04-28</ns6:attrDef-7>

<ns7:attrDef-8 xmlns:ns7="http://jantoine-xps:8080/dwa/rm/urn:rational::1-52e825ce3c6a2b0e-M-000000a2/types/" rdf:datatype="">2014-04-28T18:25:57Z</ns7:attrDef-8>

<ns8:attrDef-9 xmlns:ns8="http://jantoine-xps:8080/dwa/rm/urn:rational::1-52e825ce3c6a2b0e-M-000000a2/types/" rdf:datatype="">123</ns8:attrDef-9>

<ns9:accessControl xmlns:ns9="" rdf:resource="http://jantoine-xps:8080/dwa/rm/acp/urn:rational::1-52e825ce3c6a2b0e-F-00000000/2%252Fk%252BVk6BfLFIqG5el2X0bI%252BXzPQ%253D%250A" />

<ns10:allocatedComponent xmlns:ns10="" rdf:datatype=""></ns10:allocatedComponent>

<ns11:basisOf xmlns:ns11="" rdf:datatype=""></ns11:basisOf>

<ns12:genesysId xmlns:ns12="" rdf:datatype=""></ns12:genesysId>

<ns13:genesysName xmlns:ns13="" rdf:datatype=""></ns13:genesysName>

<ns14:heading xmlns:ns14="" rdf:datatype="">Requirement Heading</ns14:heading>

<ns15:primaryText xmlns:ns15="" rdf:datatype="">Requirement_001 Object Text</ns15:primaryText>

<ns16:specifies xmlns:ns16="" rdf:datatype=""></ns16:specifies>

<ns17:instanceShape xmlns:ns17="" rdf:resource="http://jantoine-xps:8080/dwa/rm/oslc/shape/requirement/urn:rational::1-52e825ce3c6a2b0e-M-000000a2" />

<ns18:serviceProvider xmlns:ns18="" rdf:resource="http://jantoine-xps:8080/dwa/rm/discovery/service/urn:rational::1-52e825ce3c6a2b0e-M-000000a2" />

<ns19:shortTitle xmlns:ns19="" rdf:parseType="Literal">123: Requirement Heading</ns19:shortTitle>

<ns20:contributor xmlns:ns20="" rdf:resource="http://localhost/" />

<ns21:created xmlns:ns21="" rdf:datatype="">2014-04-28T04:00:00.000000Z</ns21:created>

<ns22:creator xmlns:ns22="" rdf:resource="http://localhost/" />

<ns23:description xmlns:ns23="" rdf:parseType="Literal">Requirement Short Text</ns23:description>

<ns24:identifier xmlns:ns24="">123</ns24:identifier>

<ns25:modified xmlns:ns25="" rdf:datatype="">2014-04-28T18:25:57.000000Z</ns25:modified>

<ns26:title xmlns:ns26="" rdf:parseType="Literal">123: Requirement Heading</ns26:title>



HTTP/1.1 412 Precondition Failed

Server: Apache-Coyote/1.1

OSLC-Core-Version: 2.0

Content-Type: application/rdf+xml;charset=UTF-8

Content-Language: en

Content-Length: 310

Date: Fri, 02 May 2014 18:01:47 GMT

<?xml version="1.0"?>





<oslc:message>The etag is out of date or is invalid</oslc:message>




permanent link
Sudarshan Rao (1963) | answered May 08 '14, 4:43 a.m.
Sorry, did not see the response earlier. Did you manage to get past the problem?

I don't see anything obviously wrong with the request pasted above. Either the error is misleading, or there might be some customization within DOORS that's leading to the problem (that's a far guess though).. You may want to try it out on a simple module (just create a new module with couple of objects and check). 
In any case, if it is still an issue, its worth raising a PMR and have it formally investigated.

permanent link
Sudarshan Rao (1963) | answered May 08 '14, 4:45 a.m.
 You may also want to turn on advanced logging for DOORS Web Access, and check in oslc.log or oauth.log (these may contain some clue on what's going wrong). Instructions to enable advanced logging can be found here.

permanent link
Robert Kerr (111) | answered Dec 21 '15, 1:17 p.m.
I don't know if this is still a problem that you're fighting, but I had the same issue.  What I was finally able to discover is that ASP.NET's IfMatch tries too hard to follow the standard, whereas DOORS Web Access doesn't.  In order to get my app to work, here's what I had to do:

etag = "somestring";  //Note that this doesn't do anything special with quotes, so the etag string has no quotes in it, which is contrary to the standard

//client is an HttpClient object
client.DefaultRequestHeaders.TryAddWithoutValidation("If-Match", etag);

Then I add the other information to the request and send it.  Once I used that perturbation of the If-Match header, then DOORS Web Access accepted it.

Your answer

Register or to post your answer.