Node-solid-server: Command-line redirects, browser doesn't
$ curl -k https://solid.mit.edu/
<!DOCTYPE HTML>
<meta charset="UTF-8">
<script>
window.location.href = "https://solid.mit.edu/api/auth/select-provider?returnToUrl=https://solid.mit.edu/" + window.location.hash
</script>
<noscript>
<meta http-equiv="refresh" content="0; url=https://solid.mit.edu/api/auth/select-provider?returnToUrl=https://solid.mit.edu/">
</noscript>
<title>Redirecting...</title>
If you are not redirected automatically,
follow the <a href='https://solid.mit.edu/api/auth/select-provider?returnToUrl=https://solid.mit.edu/'>link to login</a>
Whereas just visiting https://solid.mit.edu/ in the browser works fine.
RubenVerborgh
All 12 comments
Looks like you got a 401 with curl
curl -kI https://solid.mit.edu/
HTTP/1.1 401 Unauthorized
X-Powered-By: solid-server
melvincarvalho
on 3 Jul 2018
Yeah, that's my point indeed.
The server should behave consistently for all HTTP clients.
RubenVerborgh
on 3 Jul 2018
Looks like it's an Accept header thing:
$ curl -k https://solid.mit.edu/ -H "Accept: text/html" -s | head
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta name="description" content="">
<meta name="author" content="">
<title>Solid</title>
<!-- Bootstrap core CSS -->
Yeah, this is an Accept: header thing, by design. Feel free to close the issue?
dmitrizagidulin
on 13 Jul 2018
That's broken design 馃檪 status code should be equal, regardless of accept (unless non-acceptable of course).
RubenVerborgh
on 13 Jul 2018
Wait. But AJAX requests to protected resources have one requirement, and a user accessing a protected resource has a different requirement. Hence why the dispatching logic based on Accept.
An app ajax client doesn't care about a 302 redirect, it needs a clear 401 signal (so it can prompt the user for login using its own UI, etc). Whereas a user visiting that same resource via a browser needs to be redirected to login. That's pretty standard design..
dmitrizagidulin
on 13 Jul 2018
Also, hang on. solid.mit.edu is not hosted on solid-server, is it?
dmitrizagidulin
on 13 Jul 2018
Huh, I guess it is! :) N/m.
dmitrizagidulin
on 13 Jul 2018
Ok, so that's actually a different issue. It has to do with -- solid-server has logic to turn a request for a container/ into returning (implicitly) container/index.html. But only when Accept: is text/html. So that's why you're seeing the different behavior. But again, I think that's the intended design...
dmitrizagidulin
on 13 Jul 2018
Common design, maybe, standards-compliant design, definitely not. RFC2616 doesn't let you change status codes based on Accept.
RubenVerborgh
on 13 Jul 2018
@RubenVerborgh so as far as the Apache server style implicit "return /index.html when / is requested" -- what's the standards-compliant behavior for that? To also return /index.html for plain REST requests, without accept html?
dmitrizagidulin
on 13 Jul 2018
Try to satisfy Accept, if not possible, send something else (such as HTML indeed), if not possible, 406.
RubenVerborgh
on 13 Jul 2018
Related issues
melvincarvalho
路
7Comments
RubenVerborgh
路
3Comments
ludwigschubi
路
3Comments
akuckartz
路
6Comments
Ryuno-Ki
路
5Comments
Most helpful comment
Looks like it's an
Acceptheader thing: