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
:test_bob_r_o_req a http:RequestMessage ;
http:method "DAHU" ;
http:requestURI </test-auth/alice_share_bob_r.txt> .
NSS returns 400 while I expected 405.
I think it is good practice to return a 405 for methods you do not implement, since it tends to be trivial to do and affords the client with more details to adjust its interactions. The RFC is more relaxed on this topic than I tend to be though. The question is if we should say something normative about it, and if so, should that normative statement be a MUST?
The text was updated successfully, but these errors were encountered:
For that test, 405 is precise whereas 400 would be vague. I find 405 to be more useful for clients and don't particularly see why a server would choose to return a 400 especially if the issue is strictly about the method not being available on a given resource. There is nothing wrong, faulty, unsound with the request itself. If there are other dimensions that's taken into account, 400 may be more meaningful but that'd be a different test.
I just created a test with the following request:
NSS returns
400
while I expected405
.I think it is good practice to return a
405
for methods you do not implement, since it tends to be trivial to do and affords the client with more details to adjust its interactions. The RFC is more relaxed on this topic than I tend to be though. The question is if we should say something normative about it, and if so, should that normative statement be aMUST
?The text was updated successfully, but these errors were encountered: