On Apr 3, 2:20 pm, mahemoff wrote:
> This is along the lines of what I'd like to see, but as with FND, I'd
> much rather avoid the negative term "santize_unless" if possible, and
> have it as "sanitize" instead. I have a hard time getting my head
> around "sanitize_unless: NONE".
See my response
On Apr 3, 11:19 am, FND wrote:
> > Corrupting the data is pretty much exactly what we want here.
> > [...]
> > If somebody wants text/plain they can PUT text/plain to the server and
> > it will be served back that way only.
>
> That sounds reasonable then.
> (Are text/plain PUTs stored differentl
This is along the lines of what I'd like to see, but as with FND, I'd
much rather avoid the negative term "santize_unless" if possible, and
have it as "sanitize" instead. I have a hard time getting my head
around "sanitize_unless: NONE".
Also, I had in mind the sanitise algorithm would be flexibl
> Corrupting the data is pretty much exactly what we want here.
> [...]
> If somebody wants text/plain they can PUT text/plain to the server and
> it will be served back that way only.
That sounds reasonable then.
(Are text/plain PUTs stored differently? I'll look into that to make
sure I proper
On Apr 1, 6:46 pm, FND wrote:
> > It is far more stable, predictable and performant to sanitize input
> > we get it and store the sanitized data in the datastore.
>
> While I generally agree, there's one point to consider here:
> One might argue that this sort of interference is corrupting the
> It is far more stable, predictable and performant to sanitize input
> we get it and store the sanitized data in the datastore.
While I generally agree, there's one point to consider here:
One might argue that this sort of interference is corrupting the data.
After all, you might not want to s
