I'm successfully able to view the word documents using WOPI.
Now, I'm trying to edit the document using WOPI and all wopi tests related to Locking as passing.
But when I try to edit the docx file and request the WOPI client I get this error:
I see the requests to my server for LOCK and UNLOCK. Not sure what exactly happened to fail and not requesting the PUTFILE.
Please help.
As you can see in the log, you are getting 409 Conflict during the second request.
You must provide a correct X-WOPI-Lock header to unlock the file, otherwise you'll get the 409 which means "Lock mismatch/locked by another interface".
See the documentation.
Related
Why is error 410 considered a user error (4xx) and not a redirect (3xx) or a server error (5xx)?
I request a payload from a server, and the server returns a link. I copy the link and the link gives 410? It isn't my fault to verify the link actually exists on their server. But at the same time, from the server's point of view the error originated from me, as I accessed something that doesn't exist, similar to 404 where I access something that was never there.
Can anyone help me understand the decision behind this?
Code 410
"410 Gone" client error response code indicates that access to the target resource is no longer available at the origin server and that this condition is likely to be permanent.
If you don't know whether this condition is temporary or permanent, a 404 status code should be used instead.
Why is error 410 a user error and not a server error?
It's not a "user" error, it's a client error; but yeah, that's a lousy label. The labels reflect the client-server architectural constraint, but it might be better to use labels that point more directly at the contents of the request, rather than the client (or the user).
In practice, it's a client error for the same reason that 404 is a client error; it is specifically calling attention to the target resource of the HTTP request.
In the context of the web, it does make some (imperfect) sense - the client followed a broken link (which could be a consequence of the server's current representations, but might also come from following links in stale representations, following stale bookmarks, a spelling error in a representation provided by a different server, etc).
It's not a question of fault, it just means that the request should not be considered to ever work in the future (it shouldn't be retried). Whereas a server error (like a 5xx error) could be retried periodically and should eventually work sometime in the future since the request itself is considered valid.
I'm designing a REST API. Some methods of this API are used to insert new data using the POST method. I'm wondering what error code to return when the insertion would result in duplicate data being inserted? I tried looking at the error code reference, but being quite new to REST and HTTP I'm not sure which one to use.
409 Conflict seems appropriate for that case.
The W3C status code definitions document says:
10.4.10 409 Conflict
The request could not be completed due to a conflict with the current
state of the resource. This code is only allowed in situations where
it is expected that the user might be able to resolve the conflict and
resubmit the request. The response body SHOULD include enough
information for the user to recognize the source of the conflict.
Ideally, the response entity would include enough information for the
user or user agent to fix the problem; however, that might not be
possible and is not required.
I have just set up a custom tab on my page for the first time. I have thoroughly followed the setup guide and seem to have everything on the Facebook side setup correctly.
However when I view my page it throws the following error:
Method Not Allowed The requested method GET is not allowed for the
URL /Facebook/index.html. Additionally, a 404 Not Found error was
encountered while trying to use an ErrorDocument to handle the
request. Apache/1.3.41 Server at feebnaturals.com.au Port 80
I believe it may be some kind of Apache server config issue, however I'm not that Apache savvy, so not sure where to start.
I had the same problem, but instead of GET, it was POST method which was not allowed. This is a setting on your server. Not server savvy myself, but it seems that my provider didn't allow this method on html-page, but makes no problem on doing the same for php-pages. So all I did was rename my page from .html to .php, updated the app settings in facebook and all works fine now.
This is definitely an error on your side, check your server logs and see what they say - it looks like you've configured the page to only work via a POST request and it's being requested in a GET request
Hey,
I have a REST based server, and in some cases I want to return a failure code (400 for example), BUT, I wish to add additional URL.
Something like - "failure, but here's what you can do now.."
Is there any good convention to do so?
Is it even a good idea to return error with additional information?
Thanks,
Udi
It is always a good idea to return additional information in an error message. The HTTP spec itself says so: "Except when responding to a HEAD request, the server SHOULD include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition. These status codes are applicable to any request method. User agents SHOULD display any included entity to the user."
One thing to watch out for: some versions of Internet Explorer will not show the user your additional error information if it is not a certain number of bytes. Make sure your response entities for error messages are at least 512 bytes to be sure.
I am posting (HTTP POST) various values to the posterous api. I am successfully able to upload the title, body, and ONE media file, but when I try to add in a second media file I get a server 500.
They do allow media and media[] as parameters.
How do I upload multiple files with the iPhone SDK?
The 500 your getting is probably based on one of two things:
An incorrect request
An error on the server
Now, if its an incorrect, the HTTP server would be more helpful responding back with like a 415 (unsupported media type) or something. A 500 insists that something went wrong on the server and that your request was valid.
You'll have to dig into the server API or code (if you wrote it), or read the docs and figure out what's wrong with your second request ... seems like maybe your not setting the appropriate media type?
EDIT: Ok, so I looked at the API. It appears your posting XML, so your request content-type should be
Content-Type: application/xml
The API doc didn't specifically say, but that would be the correct type.
EDIT: Actually on second glance, are you just POSTing w/URI params? Their API doc isn't clear (I'm also looking rather quickly)