place of errorCode within response structure
gabor-v opened this issue · 17 comments
Hi!
If the server (MS-FSSHTTP) responds an errorCode, when should we return it within the subResponse and when in somewhere else (like in TestCase_S17_TC02_FileOperation_ErrorCode: within the responseVersion)?
Thank you very much!
@gabor-v thanks for posting this to the issues.
Testsuite team (@ChangDu2021) the context here is that the TestCase_S17_TC02_FileOperation_ErrorCode code uses the responseVersion instead of the ResponseCollection.Response.ErrorCode which I assume would be correct. ResponseVersion looks like it would be used on GetVersions operations, not on FileOperation requests. Can you comment on this?
@tomjebo ResponseVersion is an attribute under Response, so it is not only for GetVersions operation. Please see below example:
And ErrorCode is an optional attribute in ResponseVersion.
And we are still working on gabor-v's question to investigate the difference senarios to get ErrorCode.
@ChangDu2021 thanks for looking into this. I noticed that there are ErrorCode attributes in both Response and ResponseVersion but it looks like they have slightly different functions and I think that's the confusion here.
Response.ErrorCode (from 2.2.3.5 Response):
ErrorCode: A GenericErrorCodeTypes that specifies an error code value indicating the type of error
that occurred during the processing of the mapping Request element.
ResponseVersion.ErrorCode (from 2.2.3.7 ResponseVersion):
ErrorCode: A GenericErrorCodeTypes that specifies an error code value indicating the type of error
that occurred during the processing of the mapping RequestVersion element.
I was thinking that the code in TestCase_S17_TC02_FileOperation_ErrorCode should be using Response.ErrorCode but then I'm not certain of that either. So if you can explain the usage here, that would help.
Looking at this some more, the ResponseVersion.ErrorCode is an extension of the VersionType and errors in that field should be related to the protocol version being supplied in the RequestVersion element of the request. So if the FileOperation or one of its arguments is causing a problem due to the RequestVersion being used (i.e. this specific version of the protocol doesn't support this argument), then it could make sense to use ResponseVersion.ErrorCode instead of ResponseCollection.Response.ErrorCode. The requirement for this test case, R11267 and R11268, specifically call out the Sharepoint Server versions (i.e. 2010 and 2013) but not the protocol versions (2.0, 2.1, 2.2).
@gabor-v Is where the confusion is for you?
@ChangDu2021 Can you confirm that this is why this test case is using the ResponseVersion.ErrorCode field?
I expected the errorCode within the subResponse, because the error is related with the fileOperation subRequest. Most of times it happens this way, but there are some exceptional cases (this fileOperation test case is one of them). Because of there are more possibilities where the errorCode can be set within the response structure, I would like to understand when to use them in general (subResponse.errorCode, ResponseCollection.Response.errorCode and ResponseVersion.errorCode).
If this testcase would only be interpreted for earlier versions because of the mentioned requirements, then how should the newest server and protocol version behave when we send a fileOperation subRequest without the necessary fileOperation?
If I would use Response or ResponseVersion here:
- I would say the error won't be related through subRequestToken with the original subRequest anymore, so how can I say which subRequest caused the error?
- How should I handle the case, when two subRequests cause different errors and both would use for example ResponseVersion.errorCode? We have only one ResponseVersion (MS-FSSHTTP 2.2.2.2).
- In MS-FSSHTTP 2.2.2.2 - ResponseCollection.minOccurs is 0, so it seems we won't always have one to use it's errorCode. In what cases can we have 0 ResponseCollection?
Thank you for all of you!
@gabor-v After went through the doc and verified in the source code, here is my answer and how I get it. Feel free to let me know if you have different understand.
"The response message MUST contain a ResponseVersion element and zero or more ResponseCollection elements."
So, for errorCode, when should we return it within the subResponse? We need to know when ResponseCollection is returned because sometimes ResponseCollection is not present and subResponse is in ResponseCollection.
"ResponseCollection is used to send responses for each of the file upload and download requests." It refers to Cell SubRequest. In Cell Subrequest section, it clarified that ErrorCode is returned as an attribute of SubResponse.
3.1.4.2 Cell Subrequest
So, for cell subrequest, we should get ErrorCode from Subresponse.
About another question, when should we return it within responseVersion? ErrorCode is optional attribute in ResponseVersion. But there are 3 scenarios that ErrorCode must be present. So I think, they are when we should get ErrorCode from ResponseVersion.
Please let me know if you need more detail info.
@tomjebo I don't think so. Using ResponseVersion.ErrorCode is not related with SharePoint version. After debugging the code, for FileOperationSubRequest, ResponseCollection is NULL, so, it is not available to get ErrorCode from ResponseCollection.Response.errorCode. Please see my comment above, ResponseCollection is returned for cell subrequest. So, I think, it is the reason why getting the error from ResponseVersion for FileOperationSubRequest.
@ChangDu2021 Thank you, this clarified a lot! The opened parts for me are still the following (I use here numbering to make answer-referencing more easy):
1: When I have a responseCollection, I will also have at least one subResponse inside, so if a subResponse fails with it's own errorCode, what should ResponseCollection.Response.errorCode contain? Maybe the SubRequestFail generic error outside and the Cell subRequest inside will contain a more concrete cell-specific error?
2: Does that mean I shouldn't have ResponseCollection when I don't have Cell type SubRequest at all? I haven't experienced the case when ResponseCollection is missing, even without any Cell subRequests (for example: when I had only getExclusiveLock with lockStatus or only GetDocMetaInfo alone, I always received the subResponses within ResponseCollection.Response).
If I have to return the errorCode in responseVersion (because some old client sends subRequests with version less than 2):
3: How can I decide which subRequest caused that error?
4: How should I handle the case, when two subRequests cause different errors? Because with this version both would use ResponseVersion.errorCode, but we have only one ResponseVersion (MS-FSSHTTP 2.2.2.2).
Thank you!
@tomjebo I don't think so. Using ResponseVersion.ErrorCode is not related with SharePoint version. After debugging the code, for FileOperationSubRequest, ResponseCollection is NULL, so, it is not available to get ErrorCode from ResponseCollection.Response.errorCode. Please see my comment above, ResponseCollection is returned for cell subrequest. So, I think, it is the reason why getting the error from ResponseVersion for FileOperationSubRequest.
@ChangDu2021 I agree that the ResponseVersion.ErrorCode may not be related to the Sharepoint version (directly) but according to the specification, it is related to the version in the VersionType structure for the request which I think is the protocol version for the requset. While I can believe that there is no ResponseCollection.Response.ErrorCode for this operation, I don't think it's because this operation isn't a Cell request. It looks like it's because it has to do with the argument being omitted which is related to the protocol version that was sent in the request and affects how the missing operation is handled by the server implementation.
If you look at TestCase_S17_TC01_FileOperation_Success, you'll see that it doesn't use ResponseVersion.ErrorCode.
@ChangDu2021, @gabor-v I think I start to understand the ResponseVersion.ErrorCode provision. I might be wrong on this but it looks to me like ResponseVersion will contain ErrorCode and ErrorMessage fields when effectively the entire request cannot be processed due to one of the three conditions in 2.2.3.7. Each of these conditions mean that the entire request can't be handled properly:
-
VersionType in the Request is lower than 2.0 means that the protocol server won't be able to handle the FileOperation request without an operation type and might also mean that the protocol server won't be able to handle other requests at all (?).
-
WebURL being non-existant would mean the request isn't operable at all.
-
User has no permissions for the WebURL means that the whole request would not be operable.
So perhaps this answers the question about how to determine which subRequest caused the error, for example, it doesn't matter because the entire request would be invalid.
What do you think?
@tomjebo I like the idea to use ResponseVersion.errorCode to mark the whole request validation and the subRequest.errorCode for more specific problems inside.
Yes, I think not just my previous question3, but also 4 are irrelevant, because in MS-FSSHTTP - 2.2.5.13 I found now that majorVersion can only be 2, so lower value can't be valid (sorry, my mistake).
So for me the open parts are still question1 and 2.
Thank you!
@gabor-v For question#1, I ran
MSFSSHTTP_FSSHTTPB_S04_TC04_ConvertToSchemaJoinCoauth_ConvertToSchemaFailedFileCheckedOutByCurrentUser() as an example, subresponse fails with its own error code, and the error code of its parent response is Success. So outside doesn't return SubRequestFail generic error.
For question#2, it may also have ResponseCollection when you send a non-Cell type SubRequest.
Please see below example, ResponseCollection is NULL(you means it is missing, right?).
For question#3, I think it is better to get error code from subresponse instead of responseVersion if subRequest caused the error. Please see my answer to question#1, subresponse fails but responseVersion.ErrorCode is Success.
@ChangDu2021 thank you, for me the errorCode rules seem okay now.
What I still don't understand when should I send back notNull ResponseCollection, and when the null ResponseCollection? Is there a generic rule for that?
Non-empty ResponseCollection should be if the request is valid at the high level (i.e. no version specific scenarios (like behavior note <36>) make it invalid as a whole, no invalidating conditions like file not found, etc...). Otherwise, it should be provided.
You should always pay attention to the specification when it calls out isolated cases where ResponseVersion is returned or ResponseCollection returns but otherwise, I think the above is generally the idea.
And the test 2nd FileOperation failure test case that you originally called out is driven by the requirements in the MS-FSSHTTP-FSSHTTPB_RequirementSpecification.xlsx (in the Interop-TestSuites\FileSyncandWOPI\Docs\MS-FSSHTTP-FSSHTTPB path), specifically R11267 which is driven by behavior note <36>. Just in case that wasn't clear already. :)
Non-empty ResponseCollection should be if the request is valid at the high level (i.e. no version specific scenarios (like behavior note <36>) make it invalid as a whole, no invalidating conditions like file not found, etc...). Otherwise, it should be provided. You should always pay attention to the specification when it calls out isolated cases where ResponseVersion is returned or ResponseCollection returns but otherwise, I think the above is generally the idea.
@tomjebo Thank you for your summary. @gabor-v I agree with Tom about the generic rule.
Okay, thank you for all of you, I close this issue.