Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Clarify the X-WOPI-Lock header concept #442

Open
wants to merge 3 commits into
base: master
Choose a base branch
from
Open

Clarify the X-WOPI-Lock header concept #442

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
f702cfe
Remove the prerelease flag from ClientThrottlingProtection and Reques…
RobRol Mar 17, 2021
55f2fef
Merge branch 'microsoft:master' into master
RobRol Sep 3, 2021
1a108bf
Clarify the X-WOPI-Lock Header
RobRol Sep 3, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 7 additions & 6 deletions docs/rest/src/concepts.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -127,12 +127,13 @@ understanding the requirements for integration with WOPI clients such as |wac| a
* *Not* be associated with a particular user.

All WOPI operations that modify files, such as :ref:`PutFile`, will include a lock ID as a parameter in their
request. Usually the ID will be passed in the **X-WOPI-Lock** request header (but not always;
:ref:`UnlockAndRelock` is an exception). WOPI requires that hosts compare the lock ID passed in a WOPI
request with the lock ID currently on a file and respond appropriately when the lock IDs do not match. In
particular, WOPI clients expect that when a lock ID does *not* match the current lock, the host will send
back the current lock ID in the **X-WOPI-Lock** response header. This behavior is critical, because WOPI
clients will use the current lock ID in order to determine what further WOPI calls to make to the host.
request. Usually the expected lock ID will be passed in the **X-WOPI-Lock** request header (but not always;
:ref:`UnlockAndRelock` is an exception which uses **X-WOPI-OldLock** instead). WOPI requires that hosts
compare the lock ID passed in a WOPI request with the lock ID currently on a file and respond appropriately
when the lock IDs do not match. In particular, WOPI clients expect that when a lock ID does *not* match the
current lock, the host will send back the current lock ID in the **X-WOPI-Lock** response header. This
behavior is critical, because WOPI clients will use the current lock ID in order to determine what further
WOPI calls to make to the host.

It is important to note that WOPI locks are *not* user-owned. In other words, a WOPI client may execute
lock-related operations using multiple access tokens, and hosts are expected to execute those operations as
Expand Down