MESSAGE_TOO_BIG error recommendations
Nathaniel McCallum
BadThingTM for security. Some intermediary protocols, like HTTP,
already have a TOO BIG standard error code, but many others do not. Is
there interest in a standardized code? If not, what is the
recommendation for rejecting messages that are too large?
Nathaniel McCallum
Nobody has any suggestions? I'm currently rejecting messages that are
too big (currently 64k) with a parse error, but I'm not sure this is
the right approach. I'm open to suggestions.
Lorenzo Pastrana
This issue (in terms of security) very much depends on your hardware
(memory, 32/64 bits CPU, buffer overflows etc.) .. but on your usage
also, say you are for some obscure reason on top of a MongDB server that
can take 4MB documents ... Would you limit them to 64KB ?
The questioning is undoubtedly legitimate but at implementation level, I
would say any server implementation should have a setting for this in
the confs ... for the user to tell.
The PROTOCOL obviously can't tell in advance, there is such a range of
appliances that could need/implement JSON-RPC it's impossible to give a
reasonable value ...
Lo.
Nathaniel McCallum
what is the right way to respond to objects that are too big?
Erik Nedwidek
I would like to see something that is lightweight and simple, but allows information like this to be passed back to the client. Certainly no easy task. I know there are several ideas floating around, but searching the forum right now doesn't seem to work. Starting with one of those or combining the best ideas of two or more might be the easiest way to go.
The first point would be that it should not be a part of the JSON-RPC spec, but rather an extension (see section 8). Then again I also think the first extension designed should be an extension for a server to enumerate its supported extensions. ;)
--
Erik Nedwidek
The beauty of PHP is that it is so simple even an idiot can program with it. The problem with PHP is that so many idiots do choose to program in it.
- "Code Monkey think maybe manager would like to write god damned login page himself", Code Monkey by Jonathan Coulton.
- I USHERED SOULS INTO THE NEXT WORLD. I WAS THE GRAVE OF ALL HOPE. I WAS THE ULTIMATE REALITY. I WAS THE ASSASSIN AGAINST WHOM NO LOCK WOULD HOLD.
- "Yes, point taken, but do you have any particular skills?"
-- Death consults a job broker (Terry Pratchett, Mort)
Nathaniel McCallum
too large? Something like:
-32604 | Too Large | Request object is too large
> --
> You received this message because you are subscribed to the Google Groups
> "JSON-RPC" group.
> To post to this group, send email to json...@googlegroups.com.
> To unsubscribe from this group, send email to
> json-rpc+u...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/json-rpc?hl=en.
Matt (MPCM)
wrote:
> Is there interest in a standardized error code for requests that are
> too large? Something like:
> -32604 | Too Large | Request object is too large
-32099 to -32000 Server error Reserved for implementation-defined
server-errors.
For me, this seems to be the range where such an error would belong...
not sure a standardized code is needed.
It would probably be important to distinguish between the input string
being too large prior to json parsing, and then perhaps at a request
object level in the case of batches?
I could see wanting this behavior to be variable, based on a LOT of
different circumstances. So I think the error code has value, but to
the client... it might not matter much beyond being handled like a
general server error.
Personally, 64K seems way to small for some uses of json-rpc I've had,
but I can see the rationale for wanting such a response code.
--
Matt (MPCM)
Matt (MPCM)
wrote:
> Nobody has any suggestions? I'm currently rejecting messages that are
> too big (currently 64k) with a parse error, but I'm not sure this is
> the right approach. I'm open to suggestions.
Most people in this group are not here every nite, or even every few
days, so you might want to expect more latency in your responses. :)
I would not throw a parse error, as that is misleading that there is
something wrong with the json/object. An implementation specific
error, or a general server error would be a clearer option to me.
--
Matt (MPCM)
Nathaniel McCallum
I get far lower latency when I suggest that the spec is unclear. ;)
More seriously, I'd like to propose an official "request is too big"
error code either as part of the spec (v2.1?) or as an extension. What
is the best way to do this?
Matt (MPCM)
wrote:
> I get far lower latency when I suggest that the spec is unclear. ;)
This group tends to be quiet on the whole, so your particular style of
suggestion in that thread is a quick way to get annoyed responses.
Many of us have been discussing json-rpc for years, even back to the
yahoo group days... and pre-ajax days, so lots of these issues have
been hashed out in the past. There is a trend of people suddenly
appearing, making a few posts, then demanding obvious changes, then
are never heard of again. Pattern of the internets. ;)
> More seriously, I'd like to propose an official "request is too big"
> error code either as part of the spec (v2.1?) or as an extension. What
> is the best way to do this?
Write it as an extension specification, you should be able to search
through the group history to find links to other such extensions.
In the past they used to be part of the group here, but google removed
the doc/page storage features of google groups. I have an archive of
them here:
http://jsonrpc.org/historical/
Take a look at this one, as an example:
http://jsonrpc.org/historical/json-rpc-over-http.html
I would not plan on it become part of the official spec, in general.
But rather approach it as being an extension that everyone should
*want* to adopt. Get others to adopt the extension, use the extension,
and work out the kinks (if any). This way everyone gains the benefit
of the good idea as fast as they care to implement it.
From there, if it is a good enough idea to warrant being the default
approach, it might be brought into the spec based on discussions here
and group support.
--
Matt (MPCM)
Matt (MPCM)
> appearing, making a few posts, then demanding obvious changes, then
> are never heard of again. Pattern of the internets. ;)
That should have read "demanding *obvious* (to them) changes,"
--
Matt (MPCM)