Thanks for your responses! Mine are below.
On Jun 13, 2013, at 23:38, Aria Stewart wrote:
> On Fri, Jun 14, 2013 at 09:09:33AM +0530, Hage Yaapa wrote:
>
>> What you are asking for is not recommended. Request should either be a
>> success or a failure.
>
> I concur here.
>
> Try to avoid 'warning' cases -- reduce the interface until there's only cases
> you're willing to handle separated from cases you're not. It's that much more
> surface area for the API, and that much harder to plumb together something
> that
> interprets it well.
>
> Try to take advantage of idempotency -- accept a repeated action as if it's
> the
> first time. It makes building a robust system much easier ("I'm not sure that
> worked. Send it again!")
>
> Then when you have real errors, throw the best status code and most useful
> diagnostics -- preferably in a consistent, easy to parse format -- and call it
> a day.
>
> If you need an "I know what I'm doing" flag, add it to a repeated request.
>
> TL;DR. There are no non-fatal errors, just retriable ones and non-retriable.
Part of the problem is that I am trying to create a web service around an
existing command line program that's not mine. I can't really control its
behavior. I can just give it input, and deal with its output. For various
inputs, this program's behavior is:
* output on stdout and zero exit code; I'll send a 200 OK and pipe the
program's stdout to the response
* error messages on stderr and non-zero exit code; I plan to send 400 Bad
Request to the browser with the text of the error messages
* crash and non-zero exit code; 500 Internal Server Error
* hang; I plan to set a maximum process runtime and return a 500 Internal
Server Error when it's exceeded
* output on stdout and zero exit code and error messages on stderr; this is the
case I am trying to figure out how best to handle
In the last case, as I mentioned, there are some messages the user can't do
anything about (e.g. diagnostic messages about bugs in the program being
triggered by this particular input), and there are some the user might want to
know about (e.g. requested font not found, using fallback).
For now, I'm thinking if the program produces output and a zero exit code, I'll
send it to the browser, and either just log stderr to the console, or also try
to send Warning headers as below. I can monitor what kinds of warnings are
getting logged, and decide on a case-by-case basis whether I want to promote
any of those warnings into fatal errors.
On Jun 13, 2013, at 23:55, Alex Kocharin wrote:
> Use "Warning" HTTP header. See
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
>
> It's not a "custom http header", but a standard one. ;)
Thanks, I wasn't aware of the Warning header. That's at least a possibility.
The spec says browsers "should" display these warnings to the user but I'm not
sure if any do or if I would want them to.
On Jun 14, 2013, at 01:20, Jörg Eschmann wrote:
> I would say your problem lies in your architecture.
>
> If you have a clearly structured service, the json object would be adequate.
> Generate the image and store it temporarly on your server.
> That is also good for caching, if users send the same request, you can easily
> check if the image is already available.
> Then you send the link in the json response object and fetch the image in a
> second request.
To some extent, I'm trying to model my architecture on an existing one, which
uses the described method of describing the request completely in the URL, and
receiving the desired output in the http response. But, that existing
architecture is quite old, so there might be better solutions today.
I had thought about storing the image and redirecting. It complicates the API
for consumers. I was already planning on having an (nginx?) server in front of
node to do caching.
--
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
---
You received this message because you are subscribed to the Google Groups
"nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
