Repository: https://github.com/solid/specification - Technical Reports: https://solidproject.org/TR/ - Code of Conduct: https://github.com/solid/specification#code-of-conduct
It must means resuing existing code becomes harder when we undo a basic part of such a fundamental underpinning formal specification
impossible to enumerate even
and we would like to get all that code working with Solid some day
how many of those millions of developers will go and update their code or even know that is the problem when it doesnt work in a solid world?
It fundamentally breaks backward compatibility with HTTP
of course its cleaner and safer. But I dont thnk that is the point or the main concern. Surly we need to head for ubiquity.
Different ways to look at this.
Should Solid clients know what they are sending .. where a server has some degree of trust on what it is (regardless of sniffing/processing)
So of course we will update that code. But.......that discovery led me to reading the spec and coming to the conculsion that I have come to. Hence raising the convern here and raising the issue
If some specific aspect wasn't already covered (maybe details escape me right now) or discussed in depth in solid/specification#70 , comment there perhaps for the record. Maybe nudge Tim as well :)
Thanks for bring this up (in public) by the way!
This is less of a concern for PATCH requests because there really is a no go at the moment besides application/sparql-update
PUT has likely increased in recent years but I dont have stats to back that up.
I would suspect that most POSTs on the Web are via HTML Forms in which the server processes. But yea, can't see how we'd get any stats on this.. ie. whether clients are generating a Content-Type with a valid field-value (regardless of the media type) in case where they don't actually know the format. So like text/plain or application/octet-stream at least.
according to http, the server could either inspect the content to determine the type, or could treat it an an octet-stream or could respond with an error
Right but there is this:
In practice, resource owners do not always properly configure their
origin server to provide the correct Content-Type for a given
representation, with the result that some clients will examine a
payload's content and override the specified type. Clients that do
so risk drawing incorrect conclusions, which might expose additional
security risks (e.g., "privilege escalation"). Furthermore, it is
impossible to determine the sender's intent by examining the data
format: many data formats match multiple media types that differ only
in processing semantics. Implementers are encouraged to provide a
means of disabling such "content sniffing" when it is used.
We can ensure we have a secure server.
@SharonStrats Can you elaborate on what you are looking for? Protocols, data models.. ? GPS? Geolocation API? .. We (re Solid) don't have anything on "location information" but there's stuff out there. I suspect you want something more than http://www.w3.org/2003/01/geo/wgs84_pos ?
10 replies
Hi.. Hope this question is acceptable here, feel free to send me elsewhere. I was reading the specs, I didn't see anything that would be like 'dns redirects'. For my email (and my jabber) I really like that for mydomain.org I can choose which company handles my email (via MX records) and for jabber via _xmpp txt records. Is something similar planned for solid? I'd like to be able to switch pod-providers without changing my web-id (or change what server software I run with some graceful conversion. Is that planned?
Hi @cniekel. I can tell you some of the things we are thinking about at Inrupt. I am working with the authorization panel but not the rest of the panels at the moment so this answer is not meant to be on behalf of the spec team. So you will be able to have multiple Pods associated wtih one identity. You will also be able to move Pod providers seemlessly. We would like to get to a point where you can also move providers without any links breaking. That requires 2 things. 1 - The identity uses a domain you control 2 - The Pod provider allows you to use then enture path after the domain i.e. from /. I'm sure people on the spec team will likely chime in with where the spec is at the moment with respect to those questions. I know there is the concept of pim:storage already which allows you to specify where the storage is located. Hope that helps but happy to respond to any followup questions.