[Grub-dev] Server answer codes

Tue Jan 29 17:55:48 UTC 2008

hmmm i suppose a 201 response may be appropriate as the hash is done
immediately and then the data is kept per the def on h3.org.  but IMO it
should be a 2xx code not 5xx code

mark

On Jan 29, 2008 5:51 PM, Yousef Ourabi <yourabi at zero-analog.com> wrote:

> 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
> > >
> > >
> >
>
> _______________________________________________
> 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/faf1f6cd/attachment.html 