[Grub-dev] Server answer codes

Tue Jan 29 17:51:11 UTC 2008

Let me expand a bit on my thoughts around this.

The goal of the grub system is for distributed clients to upload arc files,
have them processed / stuck in hBase.

* If we are saying the response should only be about the upload the proper
response is 201 -- resource created (I could be swayed by this)

* I'm almost tempted to propose a 1xx response, since semantically that is
what is happening, we received your request, and we have to do more
processing -- but I've never seen 1xx in the wild.

* If we treat hBase as part of the destination, ie we are creating this
resource in hBase vs a plain old file-system, and we are unable to complete
it but the request was valid this would be a 5xx

I'm leaning towards the last option, since logically I consider hBase the
destination of the resource being put'ed -- not jst some tmp/transient file
systemo on local disk.

On 1/29/08, Yousef Ourabi <yourabi at zero-analog.com> wrote:
>
> I'm going to continue raising a stink from this. IF we are going to do a
> REST interface, we are going to do it the right way.  You'll note the
> description of the 500 erros:
>
> 5xx: Server Error - The server failed to fulfill an apparently valid request
>
>
>
>
>
>
> 6.1.1 Status Code and Reason Phrase
>
> The Status-Code element is a 3-digit integer result code of the attempt to
> understand and satisfy the request. These codes are fully defined in section
> 10. The Reason-Phrase is intended to give a short textual description of the
> Status-Code. The Status-Code is intended for use by automata and the
> Reason-Phrase is intended for the human user. The client is not required to
> examine or display the Reason- Phrase.
>
> The first digit of the Status-Code defines the class of response. The last
> two digits do not have any categorization role. There are 5 values for the
> first digit:
>
>       - 1xx: Informational - Request received, continuing process
>
>       - 2xx: Success - The action was successfully received,
>         understood, and accepted
>
>       - 3xx: Redirection - Further action must be taken in order to
>         complete the request
>
>       - 4xx: Client Error - The request contains bad syntax or cannot
>         be fulfilled
>
>       - 5xx: Server Error - The server failed to fulfill an apparently
>         valid request
>
>
>
>
>
> On 1/29/08, seth <seth at untethered.org> wrote:
> >
> > That was my thinking as well.  We got your data, the hash check doesn't
> > require HBase at all, so we even know that your work unit is valid.  We
> > just weren't able to do all the server side work, but we were able to do
> > enough that it doesn't require end-user interaction for the server to
> > recover.  I have a script that can load the work units that were submitted
> > when the script was returning 202 codes.  I just have to grep the logs for
> > them and run the script.
> > So, in my mind, even though HBase was having problems, it was
> > a partial success and the client should feel free to continue gathering more
> > URLs.  Just means more work for me after I get HBase fixed.
> >
> > seth
> >
> >
> > On Jan 29, 2008, at 11:33 AM, Mark (Markie) wrote:
> >
> > well it was a success, the files were saved, just not implemented/used
> > yet, but a 500 would suggest that it was not received, hmmm...
> >
> > mark
> >
> >
> >
> > On Jan 29, 2008 4:58 PM, Yousef Ourabi <yourabi at zero-analog.com> wrote:
> >
> > > i'm not sure 202 is the best for an error message regarding hbase --
> > > section 6.1.1 of rfc 2616 is pretty clear that 2xx is success only --
> > > while one could make the argument that the "client" side was successful, I
> > > think a 5xx would be more appropriate... since there was a problem, and it
> > > was clearly on the server side...
> > >
> > > input?
> > >
> > >
> > >
> > >
> > >
> > > On 1/29/08, jer <jeremie at jabber.org> wrote:
> > > >
> > > > > 401 errors are most likely client errors.  It means that the URLs
> > > > > that were returned in the work unit don't match those that were
> > > > sent
> > > > > out.  The URLs that are returned need to be in the same order as
> > > > the
> > > > > were in the work unit, and there can't be any missing.
> > > >
> > > > To be even more pedantic, if you are getting these it might help to
> > > > understand exactly what it's validating.  The hash code is generated
> > > > by doing a cumulative:
> > > >
> > > >         for each workunit entry
> > > >                 hash = sha1hex( last-hash + " " + hostname + " " +
> > > > path )
> > > >
> > > > The hostname and path that are placed into the resulting arc must be
> > > > exactly the one in the given Host: header and path in the GET
> > > > request
> > > > line.
> > > >
> > > > It's important that we validate these to at least prevent URL
> > > > injection through this API, that clients are only returning the URLs
> > > > that they were assigned.
> > > >
> > > > Jer
> > > >
> > > > _______________________________________________
> > > > Grub-dev mailing list
> > > > Grub-dev at wikia.com
> > > > http://lists.wikia.com/mailman/listinfo/grub-dev
> > > >
> > >
> > >
> > > _______________________________________________
> > > Grub-dev mailing list
> > > Grub-dev at wikia.com
> > > http://lists.wikia.com/mailman/listinfo/grub-dev
> > >
> > >
> > _______________________________________________
> > Grub-dev mailing list
> > Grub-dev at wikia.com
> > http://lists.wikia.com/mailman/listinfo/grub-dev
> >
> >
> >
> > _______________________________________________
> > Grub-dev mailing list
> > Grub-dev at wikia.com
> > http://lists.wikia.com/mailman/listinfo/grub-dev
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.wikia.com/pipermail/grub-dev/attachments/20080129/f5dfe7d6/attachment-0001.html 