On Jul 6, 10:11 am, "Bob Ippolito" <[EMAIL PROTECTED]> wrote:

> It works 100% of the time. If you're doing something obscure with
> status codes (anything obscure, even successful codes that aren't
> 2xx), you need to use an extra three lines of code in this case. That
> doesn't mean it's broken.

The OP wants 2xx codes to be "success", but your remark above "even
successful codes that aren't 2xx" makes me wonder if you think the OP
is talking about  non-2xx status codes.

My reading of this thread is that the OP wants any 2xx code to be a
success because that's the way RFC2616 reads.

I apologize for being presumptuous and post this excerpt
from http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

---

10.2 Successful 2xx

This class of status code indicates that the client's request was
successfully received, understood, and accepted

---

My take on this is that any 2xx status code should be treated as
success, regardless if it's "commonly seen in the wild".

It's true, it's only 3 lines of code to add.

But, that's three lines for the OP, and three lines I need to add to
all my client's projects, and 3 lines that others will be adding to
their code in the future.

This behavior is not something I'd expect, since (at least my reading
of RFC2616) is that any 2xx should be treated as successful.

Sometimes there's a conflict between what a spec says, and what's been
commonly coded and deployed. In those cases pragmatic code is good
because it works with what's in the wild, even if that doesn't match
the specification.

But in this particular case, I can't think of any server/service
returning a "non-common" 2xx code that means "failure".

----

Following up on what Arnar said, another advantage to MochiKit is that
it doesn't do anything unexpected. So, for example, differences
between IE and other DOM implementations are hidden away and
everything just "works".

For that, I love MochiKit.

But in this particular case, treating 2xx as non-success *is*
unexpected to the OP, and unexpected to me.

Is there some reason other than "it's only 3 lines of code to fix"
that this behavior should not be changed in MochiKit?

Thanks,

-B


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"MochiKit" 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/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to