You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
SHOULD is defined in http://www.ietf.org/rfc/rfc2119.txt as "SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course." So we probably should. :)
I just looked at the addResource method in MediaResourceManagerImpl and the MD5 is available (assuming the client sends it, which we haven't encouraged at all) from deposit.getMd5(). That is to say, it should be pretty straightforward to check. Of course, we currently require that all files uploaded via API (SWORD) be zip files (see #1612 about how people want non-zips).
At #1612 (comment) I opined that we should develop a "native" API endpoint for uploading files so we won't be constrained by SWORD (and we certainty still should) but in this case SWORD has it right. We might as well start by adding checksum verification in our SWORD API since the spec compels us to do so. Then we can encourage clients to start sending checksums. The spec says, "The client SHOULD supply a Content-MD5 header with the MD5 checksum hex encoded for the binary content."
The text was updated successfully, but these errors were encountered:
@pameyer originally brought this up at #952 (comment) but it deserves its own issue.
The SWORDv2 spec says we "The server SHOULD verify the Content-MD5 header against the content. If the check fails, the server MUST respond with 412 Precondition Failed, and MAY return a SWORD Error document" at http://swordapp.github.io/SWORDv2-Profile/SWORDProfile.html#protocoloperations_addingcontent
SHOULD is defined in http://www.ietf.org/rfc/rfc2119.txt as "SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course." So we probably should. :)
I just looked at the addResource method in MediaResourceManagerImpl and the MD5 is available (assuming the client sends it, which we haven't encouraged at all) from deposit.getMd5(). That is to say, it should be pretty straightforward to check. Of course, we currently require that all files uploaded via API (SWORD) be zip files (see #1612 about how people want non-zips).
At #1612 (comment) I opined that we should develop a "native" API endpoint for uploading files so we won't be constrained by SWORD (and we certainty still should) but in this case SWORD has it right. We might as well start by adding checksum verification in our SWORD API since the spec compels us to do so. Then we can encourage clients to start sending checksums. The spec says, "The client SHOULD supply a Content-MD5 header with the MD5 checksum hex encoded for the binary content."
The text was updated successfully, but these errors were encountered: