2:32 p.m.
support optimistic locking with ETags and If-Match in rest server
-----------------------------------------------------------------
Key: ISPN-1084
URL: https://issues.jboss.org/browse/ISPN-1084
Project: Infinispan
Issue Type: Feature Request
Components: Cache Server
Affects Versions: 5.0.0.CR1, 4.2.2.BETA1
Reporter: Michal Linhard
Assignee: Trustin Lee
currently it is not possible to do optimistic locking using the ETag feature in the REST
server, because the "If-Match" HTTP header is ignored.
We allow to put a value many times with the same "If-Match" header, but
according to the spec:
{quote}
"A request intended to update a resource (e.g., a PUT) MAY include an If-Match header
field to signal that the request method MUST NOT be applied if the entity corresponding to
the If-Match value (a single entity tag) is no longer a representation of that resource.
This allows the user to indicate that they do not wish the request to be successful if the
resource has been changed without their knowledge. "
{quote}
(copied from http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.24)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
1:54 p.m.
New subject: [JBoss JIRA] Updated: (ISPN-1084) support optimistic locking with ETags and If-Match in rest server
[
https://issues.jboss.org/browse/ISPN-1084?page=com.atlassian.jira.plugin....
]
Manik Surtani updated ISPN-1084:
--------------------------------
Fix Version/s: 5.0.0.CR2
5.0.0.FINAL
support optimistic locking with ETags and If-Match in rest server
-----------------------------------------------------------------
Key: ISPN-1084
URL: https://issues.jboss.org/browse/ISPN-1084
Project: Infinispan
Issue Type: Feature Request
Components: Cache Server
Affects Versions: 4.2.2.BETA1, 5.0.0.CR1
Reporter: Michal Linhard
Assignee: Trustin Lee
Fix For: 5.0.0.CR2, 5.0.0.FINAL
currently it is not possible to do optimistic locking using the ETag feature in the REST
server, because the "If-Match" HTTP header is ignored.
We allow to put a value many times with the same "If-Match" header, but
according to the spec:
{quote}
"A request intended to update a resource (e.g., a PUT) MAY include an If-Match
header field to signal that the request method MUST NOT be applied if the entity
corresponding to the If-Match value (a single entity tag) is no longer a representation of
that resource. This allows the user to indicate that they do not wish the request to be
successful if the resource has been changed without their knowledge. "
{quote}
(copied from http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.24)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12:59 a.m.
New subject: [JBoss JIRA] Updated: (ISPN-1084) support optimistic locking with ETags and If-Match in rest server
[
https://issues.jboss.org/browse/ISPN-1084?page=com.atlassian.jira.plugin....
]
Manik Surtani updated ISPN-1084:
--------------------------------
Fix Version/s: 5.0.0.CR3
(was: 5.0.0.CR2)
support optimistic locking with ETags and If-Match in rest server
-----------------------------------------------------------------
Key: ISPN-1084
URL: https://issues.jboss.org/browse/ISPN-1084
Project: Infinispan
Issue Type: Feature Request
Components: Cache Server
Affects Versions: 4.2.2.BETA1, 5.0.0.CR1
Reporter: Michal Linhard
Assignee: Trustin Lee
Fix For: 5.0.0.CR3, 5.0.0.FINAL
currently it is not possible to do optimistic locking using the ETag feature in the REST
server, because the "If-Match" HTTP header is ignored.
We allow to put a value many times with the same "If-Match" header, but
according to the spec:
{quote}
"A request intended to update a resource (e.g., a PUT) MAY include an If-Match
header field to signal that the request method MUST NOT be applied if the entity
corresponding to the If-Match value (a single entity tag) is no longer a representation of
that resource. This allows the user to indicate that they do not wish the request to be
successful if the resource has been changed without their knowledge. "
{quote}
(copied from http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.24)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
7:45 a.m.
New subject: [JBoss JIRA] Updated: (ISPN-1084) support optimistic locking with ETags and If-Match in rest server
[
https://issues.jboss.org/browse/ISPN-1084?page=com.atlassian.jira.plugin....
]
Trustin Lee updated ISPN-1084:
------------------------------
Fix Version/s: 5.1.0.BETA1
5.1.0.Final
(was: 5.0.0.FINAL)
(was: 5.0.0.CR3)
This is a new feature - should be scheduled for 5.1.
support optimistic locking with ETags and If-Match in rest server
-----------------------------------------------------------------
Key: ISPN-1084
URL: https://issues.jboss.org/browse/ISPN-1084
Project: Infinispan
Issue Type: Feature Request
Components: Cache Server
Affects Versions: 4.2.2.BETA1, 5.0.0.CR1
Reporter: Michal Linhard
Assignee: Trustin Lee
Fix For: 5.1.0.BETA1, 5.1.0.Final
currently it is not possible to do optimistic locking using the ETag feature in the REST
server, because the "If-Match" HTTP header is ignored.
We allow to put a value many times with the same "If-Match" header, but
according to the spec:
{quote}
"A request intended to update a resource (e.g., a PUT) MAY include an If-Match
header field to signal that the request method MUST NOT be applied if the entity
corresponding to the If-Match value (a single entity tag) is no longer a representation of
that resource. This allows the user to indicate that they do not wish the request to be
successful if the resource has been changed without their knowledge. "
{quote}
(copied from http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.24)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
8:17 a.m.
New subject: [JBoss JIRA] Assigned: (ISPN-1084) support optimistic locking with ETags and If-Match in rest server
[
https://issues.jboss.org/browse/ISPN-1084?page=com.atlassian.jira.plugin....
]
Tristan Tarrant reassigned ISPN-1084:
-------------------------------------
Assignee: Tristan Tarrant (was: Trustin Lee)
support optimistic locking with ETags and If-Match in rest server
-----------------------------------------------------------------
Key: ISPN-1084
URL: https://issues.jboss.org/browse/ISPN-1084
Project: Infinispan
Issue Type: Feature Request
Components: Cache Server
Affects Versions: 4.2.2.BETA1, 5.0.0.CR1
Reporter: Michal Linhard
Assignee: Tristan Tarrant
Fix For: 5.1.0.BETA1, 5.1.0.FINAL
currently it is not possible to do optimistic locking using the ETag feature in the REST
server, because the "If-Match" HTTP header is ignored.
We allow to put a value many times with the same "If-Match" header, but
according to the spec:
{quote}
"A request intended to update a resource (e.g., a PUT) MAY include an If-Match
header field to signal that the request method MUST NOT be applied if the entity
corresponding to the If-Match value (a single entity tag) is no longer a representation of
that resource. This allows the user to indicate that they do not wish the request to be
successful if the resource has been changed without their knowledge. "
{quote}
(copied from http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.24)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
8:50 a.m.
New subject: [JBoss JIRA] Commented: (ISPN-1084) support optimistic locking with ETags and If-Match in rest server
[
https://issues.jboss.org/browse/ISPN-1084?page=com.atlassian.jira.plugin....
]
Tristan Tarrant commented on ISPN-1084:
---------------------------------------
I am working on getting the full implementation of this working (including all variations
of If-Match, If-None-Match, If-Modified-Since, If-Unmodified-Since) for all methods (PUT,
GET, DELETE): the RESTEasy bits make it relatively easy
support optimistic locking with ETags and If-Match in rest server
-----------------------------------------------------------------
Key: ISPN-1084
URL: https://issues.jboss.org/browse/ISPN-1084
Project: Infinispan
Issue Type: Feature Request
Components: Cache Server
Affects Versions: 4.2.2.BETA1, 5.0.0.CR1
Reporter: Michal Linhard
Assignee: Tristan Tarrant
Fix For: 5.1.0.BETA1, 5.1.0.FINAL
currently it is not possible to do optimistic locking using the ETag feature in the REST
server, because the "If-Match" HTTP header is ignored.
We allow to put a value many times with the same "If-Match" header, but
according to the spec:
{quote}
"A request intended to update a resource (e.g., a PUT) MAY include an If-Match
header field to signal that the request method MUST NOT be applied if the entity
corresponding to the If-Match value (a single entity tag) is no longer a representation of
that resource. This allows the user to indicate that they do not wish the request to be
successful if the resource has been changed without their knowledge. "
{quote}
(copied from http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.24)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:23 a.m.
New subject: [JBoss JIRA] Updated: (ISPN-1084) support optimistic locking with ETags and If-Match in rest server
[
https://issues.jboss.org/browse/ISPN-1084?page=com.atlassian.jira.plugin....
]
Galder Zamarreño updated ISPN-1084:
-----------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 5.1.0.ALPHA1
(was: 5.1.0.BETA1)
Resolution: Done
support optimistic locking with ETags and If-Match in rest server
-----------------------------------------------------------------
Key: ISPN-1084
URL: https://issues.jboss.org/browse/ISPN-1084
Project: Infinispan
Issue Type: Feature Request
Components: Cache Server
Affects Versions: 4.2.2.BETA1, 5.0.0.CR1
Reporter: Michal Linhard
Assignee: Tristan Tarrant
Fix For: 5.1.0.ALPHA1, 5.1.0.FINAL
currently it is not possible to do optimistic locking using the ETag feature in the REST
server, because the "If-Match" HTTP header is ignored.
We allow to put a value many times with the same "If-Match" header, but
according to the spec:
{quote}
"A request intended to update a resource (e.g., a PUT) MAY include an If-Match
header field to signal that the request method MUST NOT be applied if the entity
corresponding to the If-Match value (a single entity tag) is no longer a representation of
that resource. This allows the user to indicate that they do not wish the request to be
successful if the resource has been changed without their knowledge. "
{quote}
(copied from http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.24)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:23 a.m.
New subject: [JBoss JIRA] Updated: (ISPN-1084) support optimistic locking with ETags and If-Match in rest server
[
https://issues.jboss.org/browse/ISPN-1084?page=com.atlassian.jira.plugin....
]
Galder Zamarreño updated ISPN-1084:
-----------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/513
support optimistic locking with ETags and If-Match in rest server
-----------------------------------------------------------------
Key: ISPN-1084
URL: https://issues.jboss.org/browse/ISPN-1084
Project: Infinispan
Issue Type: Feature Request
Components: Cache Server
Affects Versions: 4.2.2.BETA1, 5.0.0.CR1
Reporter: Michal Linhard
Assignee: Tristan Tarrant
Fix For: 5.1.0.ALPHA1, 5.1.0.FINAL
currently it is not possible to do optimistic locking using the ETag feature in the REST
server, because the "If-Match" HTTP header is ignored.
We allow to put a value many times with the same "If-Match" header, but
according to the spec:
{quote}
"A request intended to update a resource (e.g., a PUT) MAY include an If-Match
header field to signal that the request method MUST NOT be applied if the entity
corresponding to the If-Match value (a single entity tag) is no longer a representation of
that resource. This allows the user to indicate that they do not wish the request to be
successful if the resource has been changed without their knowledge. "
{quote}
(copied from http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.24)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
4603
days inactive
4734
days old
infinispan-issues@lists.jboss.org
7 comments
5 participants
participants (5)
-
Galder Zamarreño (JIRA) -
Manik Surtani (JIRA)
-
Michal Linhard (JIRA)
-
Tristan Tarrant (JIRA)
-
Trustin Lee (JIRA)