Some host rely on the auth header because they are using their oauth stack. We have no way for a host to indicate that they are using oauth so we include both for safety.

See the WOPI discovery section.

• IP ACLs
• Authentication
• Editors must be edge-to-edge frames; viewers can be lightboxed, though (maybe this belongs in #49 instead?)

A PutFile operation on a file that is not locked AND zero bytes must be executed. In other words, in some cases Office Online will send PutFile requests on files that are not yet locked, and those operations should be honored iff the file is zero bytes in size. (we need this for the Create New – 0byte file - flow)

Related to issue #2.

• X-WOPI-AppEndpoint: a string used to indicate the endpoint of the Office Online app sending the request – typically used to indicate geographic location, datacenter, etc. Should be treated like an opaque string by the host.
• X-WOPI-HostEndpoint: a string used to indicate the endpoint of the WOPI host handling the request – typically used to indicate geographic location, datacenter, etc. Office Online treats this as an opaque string, but logs it for troubleshooting purposes.

The default blue link style looks terrible on the purple background

• UI_ReportAbuse
• UI_ReplyWithChanges
• UI_OpenInClient
• UI_RedeemForCommenting
• UI_FileEmbed
• UI_FileProperties
• UI_ShareForm
• CheckPolicy
• CheckPolicyResponse
• QueryLoadingStatus
• App_TempError
• App_AllOK
• App_FatalError
• App_Navigated

• Preloading static content
• Optimizing document viewing for high volume
  • SHA256
    • If this is not provided, we'll generate a cache key using the file ID and version of the file. Not as reliable; we prefer SHA256 if possible
  • UniqueContentId
  • DisableBrowserCachingOfUserContent

Also need to include performance targets for WOPI operations such as CheckFileInfo.

Also call out the TCP sliding window size extension info for network performance.

From @MarcinJuraszek:

There is a pair of inputs for each of possible cases:

1. Validate successfully using X-WOPI-Proof and current Key from Discovery
2. Validate successfully using X-WOPI-ProofOld and current Key from Discovery
3. Validate successfullyusing X-WOPI-Proof and old Key from Discovery
4. Validation fails

I generated those using custom certificate, all the keys information is included in the test code itself so it's not bound to any Certificate changes we make in our environments.

You can find the code on Gist: https://gist.github.com/MarcinJuraszek/54477a568c9a2ed851ef - just change ProofKeysHelper.Validate() method with your implementation of Proof Keys validation logic.

X-WOPI-OverwriteRelativeTarget indicates that if the filename we pass with PutRelative already exists, overwrite the file. Otherwise, hosts should return a 409 error with a suggested new file name. In Excel there is a checkbox that gives the user the option to do this on Save As; this is the only place today that this header is set.

Answer: CheckFileInfo and GetFile

Is this message shown to the user?

HTTP headers are case-insensitive, per RFC 7230 Section 3.2:

Each header field consists of a case-insensitive field name followed by a colon (":"), optional leading whitespace, the field value, and optional trailing whitespace.

However, we should be consistent when we refer to the headers, and use X-WOPI- in all caps as the prefix, and camel-casing for the rest of the header name, e.g. X-WOPI-OldLock.

Unfortunately, due to the behavior of sphinxcontrib-httpdomain in version 1.3.0, the header values are automatically title-cased in the REST parts of the docs. This issue is actually already fixed in the next version of sphinxcontrib-httpdomain, and I have asked the developer to publish an updated version since 1.3.0 is quite old at this point. Until that's done we'll have inconsistencies.

• Editors must be edge-to-edge frames; viewers can be lightboxed, though
• Hosts are expected to allow transitions from view to edit directly whenever applicable (i.e. the user has rights and edit is supported)
  • This means they need to provide access tokens that are scoped properly for both view and edit and set SupportsUpdate and UserCanWrite, etc.
• Use the branding toolkit, and/or favicons from discovery

• syndicate
• legacywebservice
• rtc
• collab
• documentchat

• Passing access tokens securely

Right now the WOPI operations are all grouped by the endpoint they're exposed on, which makes some sense organizationally, but in practice the endpoints are largely irrelevant, while the operations are very interesting. Right now the docs make it a bit hard to find, for example, CheckFileInfo. Maybe we should just move the endpoints to a reference section and expose the operations at a higher level?

Need to clarify the lock requirements, especially around lock mismatches and the headers that should be returned by the host.

Seems like we could doc this in one of two ways:

1. Provide a list of acceptable domains.
2. Provide specific guidance on using the domain from the action URL they created to invoke the app.

• DownloadUrl and HostEditUrl are required on CheckFile response to perform License Check flow
• LicensedOrganization

Are X-WOPI-RelativeTarget and X-WOPI-SuggestedTarget mutually exclusive?