Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

with NSS returns : $ | data types don't match (LIST:STRING) #116

Closed
bourgeoa opened this issue Jan 10, 2024 · 12 comments · Fixed by #117
Closed

with NSS returns : $ | data types don't match (LIST:STRING) #116

bourgeoa opened this issue Jan 10, 2024 · 12 comments · Fixed by #117

Comments

@bourgeoa
Copy link
Member

bourgeoa commented Jan 10, 2024

| HEAD | [200] | == '' |
expected

| HEAD | [200] | == '' |

@edwardsph
Copy link
Collaborator

The HTTP specs seem clear that the server should not return a body on a HEAD request: https://www.rfc-editor.org/rfc/rfc9110.html#name-head

@bourgeoa bourgeoa changed the title NSS return [] expected blank with NSS returns : $ | data types don't match (LIST:STRING) Jan 12, 2024
@bourgeoa
Copy link
Member Author

Sorry. I was not clear with the issue.

20:51:16.802 ../data/protocol/cors/acao-vary.feature:14
And match response == ''
match failed: EQUALS
$ | data types don't match (LIST:STRING)
[]
''

../data/protocol/cors/acao-vary.feature:14

There is no body but the data type is not the expected one.

@edwardsph
Copy link
Collaborator

That does look like a possible bug in the test but I am unable to reproduce it as the tests now fail earlier. I'm running against inrupt.net on version 5.7.8 and all these tests fail with a 403 response when 200 was expected:

✗ Access-Control-Allow-Origin header is set to correct origin for GET on container
✗ Access-Control-Allow-Origin header is set to correct origin for HEAD on container
✗ Vary header includes Origin for GET on container
✗ Vary header includes Origin for HEAD on container
✗ Access-Control-Allow-Origin header is set to correct origin for GET on resource
✗ Access-Control-Allow-Origin header is set to correct origin for HEAD on resource
✗ Vary header includes Origin for GET on resource
✗ Vary header includes Origin for HEAD on resource

Are you still seeing the original problem? If so, how can I reproduce it?

@bourgeoa
Copy link
Member Author

bourgeoa commented Jan 15, 2024

Issue is still there.

I run the tests against the test server https://solidcommunity.net:8443
This server is running NSS v5.7.9-beta branch with my latest updates

@edwardsph
Copy link
Collaborator

edwardsph commented Jan 15, 2024

Ah - that explains it. I only test the released version.
By the way, that server homepage says it is running 5.7.3 and the repo says the latest release is 5.7.7. If you can tidy these up and ensure any issues are explicit about the version they relate to that would really help diagnostics.

@bourgeoa
Copy link
Member Author

tiddy done. Thanks

@edwardsph
Copy link
Collaborator

I tried to create a test account on solidcommunity.net and add a trusted app but I cannot edit my WebID document. Just adding the fragment and saving gives the error:

Statement to be removed is not on store: <https://spectestalice.solidcommunity.net/profile/card#me> <http://www.w3.org/2007/ont/link#document> <https://spectestalice.solidcommunity.net/profile/card>

I can't get any further. If you want to send me credentials for a test account for alice, I will try again

@bourgeoa
Copy link
Member Author

I looked at the tests in NSS. The empty body check is made against response.text

  const emptyResponse = function (res) {
    if (res.text) {
      throw new Error('Not empty response')
    }

this is the cat nss.env

quarkus.log.category."org.solid.testharness.http.Client".level=DEBUG

USERS_ALICE_WEBID=https://alice.solidcommunity.net:8443/profile/card#me
USERS_BOB_WEBID=https://bob.solidcommunity.net:8443/profile/card#me

LOGIN_ENDPOINT=https://solidcommunity.net:8443/login/password
USERS_ALICE_USERNAME=alice
USERS_ALICE_PASSWORD=123
USERS_ALICE_IDP=https://solidcommunity.net:8443/
USERS_BOB_USERNAME=bob
USERS_BOB_PASSWORD=123
USERS_BOB_IDP=https://solidcommunity.net:8443/

@bourgeoa
Copy link
Member Author

I tried to create a test account on solidcommunity.net and add a trusted app but I cannot edit my WebID document. Just adding the fragment and saving gives the error:

Statement to be removed is not on store: <https://spectestalice.solidcommunity.net/profile/card#me> <http://www.w3.org/2007/ont/link#document> <https://spectestalice.solidcommunity.net/profile/card>

I can't get any further. If you want to send me credentials for a test account for alice, I will try again

This is a painful known issue recently introduced in rdflib.js
Just close the message and redo the update. It may reappear twice but finally will update with your changes.

@edwardsph
Copy link
Collaborator

I've run the acao-vary test against this server and I can see that the body is empty. However, I think the karate response tests are confused by the fact that the server is reporting a content length of 2 despite it being empty.
1 > HEAD https://alice.solidcommunity.net:8443/shared-test/VLxVag/j3NyaY/
1 > Authorization: DPoP ***FKzAzw
1 > User-Agent: Solid-Conformance-Test-Suite
1 > DPoP: ***UdUpXg
1 > Origin: https://tester
1 > Host: alice.solidcommunity.net:8443
1 > Connection: Keep-Alive
1 > Accept-Encoding: gzip,deflate

2024-01-16 08:48:51,455 DEBUG [com.int.karate] (main) response time in milliseconds: 206
1 < 200
1 < X-Powered-By: solid-server/5.7.9-beta
1 < Access-Control-Allow-Origin: https://tester
1 < Vary: Accept, Authorization, Origin
1 < Access-Control-Allow-Credentials: true
1 < Access-Control-Expose-Headers: Authorization, User, Location, Link, Vary, Last-Modified, ETag, Accept-Patch, Accept-Post, Updates-Via, Allow, WAC-Allow, Content-Length, WWW-Authenticate, MS-Author-Via, X-Powered-By
1 < Allow: OPTIONS, HEAD, GET, PATCH, POST, PUT, DELETE
1 < Link: <.acl>; rel="acl", <.meta>; rel="describedBy", http://www.w3.org/ns/ldp#Container; rel="type", http://www.w3.org/ns/ldp#BasicContainer; rel="type"
1 < Access-Control-Allow-Methods: HEAD,GET,PATCH,POST,PUT,DELETE,OPTIONS
1 < WAC-Allow: user="read write append control",public=""
1 < MS-Author-Via: SPARQL
1 < Updates-Via: wss://alice.solidcommunity.net:8443
1 < Content-Type: application/octet-stream; charset=utf-8
1 < Content-Length: 2
1 < ETag: W/"2-nOO9QiTIwXgNtWtBJezz8kv3SLc"
1 < Set-Cookie: nssidp.sid=s%3AqZGm2zgS1k2rgI9xGsoeQcNYuVTvQeRQ.zvdu%2FsIergopIKRTwrESnnWGOL3aPu%2Fgo6Cb6qm%2BzPI; Domain=.solidcommunity.net; Path=/; Expires=Wed, 17 Jan 2024 08:48:53 GMT; HttpOnly; Secure
1 < Date: Tue, 16 Jan 2024 08:48:53 GMT
1 < Connection: keep-alive
1 < Keep-Alive: timeout=5

Can you see if fixing the content length resolves the problem?

@edwardsph
Copy link
Collaborator

Sorry, that is not actually the issue since it is valid for content-length to be non-zero since it represents the length of the content that would be returned for a GET.
The problem is actually caused by the Content-Type header which is Content-Type: application/octet-stream; charset=utf-8. The Karate framework is treating that as an array of bytes. I can cast the response to a string and then the tests work. However, I think that NSS is mistaken in returning that content type. The response to a HEAD request is supposed to provide the headers that would be returned if it was a GET request and therefore the content type should be text/turtle for a container. Even if I set the accept header to text/turtle, I still get application/octet-stream.

@bourgeoa
Copy link
Member Author

bourgeoa commented Jan 17, 2024

You are right NSS is mistakenly returning Content-Type: application/octet-stream; charset=utf-8 for HEAD on Container.

I tested the conformance-tests and the issue is resolved. To implement the change I shall either do it resource-mapper.js or in GET --> HEAD in ldp.js. resource-mapper.js may be the cleanest.

resolved with commit nodeSolidServer/node-solid-server@fbd30b0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants