211–220 of 416 posts
Web servers and http enabled services can limit the length of headers and url. While this can be done it runs the risk of having surprises when unknown limits are encountered. Most of these limits are buried deep in docs, not easily visible.
Earlier quoted context omitted.
[flagged]
I did once and was told off for adding noise to the discussion by someone who didn't see the irony of their complaint also adding to the noise.
Earlier quoted context omitted.
> The disadvantages are that your representation of internal state becomes part of the interface This is the biggest reason to avoid this. URLs aren't meant to be used this way. I'd only do it if I wanted a quick and dirty solution.
> URLs aren't meant to be used this way I disagree, URLs are supposed to point to a resource - in this case the resource is the client state of the app (aka "deep linking"). It is a useful approach. Of course, it can easily be misused.
Earlier quoted context omitted.
The possible advantage of the encoding is that it that it can be encrypted and make parameter hacking impossible.
Would have to do the signing server-side, predicated on the server checking the entire state to ensure validity. Such effort being put into preventing parameter-hacking would suggest there are serious vulnerabilities in that website. The URL is meant to be modified by the client.
Clarification, the human user probably won't want to modify the URL, but the client will.
This is pretty common and has a bunch of advantages, like the fact you can link to and bookmark a particular state. Also, if you are careful you get undo and redo for free with the browser's back button doing all the work for you. The disadvantages are that your representation of internal state becomes part of the interface - if you ever change your app you need to deal with versioning the state so your new version c…
Conversely, you can't link to the newest version.
Earlier quoted context omitted.
A colleague has been tasked with writing a remote image viewer. It’s slower than before (running on the same machine) “because it’s client-server”. Naturally, the 16 Megapixel images are sent as an array of json floats…
Unless it's still at a proof-of-concept stage, that person is out of their depth.
Extra fun fact: Two years into the project, they hadn't heard of REST. Then rejected it, because, I quote, "The S means stateless and [they] need the server to store state"
Earlier quoted context omitted.
base64 does not have the problem here, iMessage has. Frustrating.
Curious if English is your mother tongue, and if so, which locale? As a native speaker of en-US, I would write this as "base64 does not have the problem here, iMessage does."