pport. Also we should be keeping closer tabs on how the
HTTPbis efforts at the IETF are doing, as a newer replacement protocol
should definitely be coherent with that.
In the mean time, I'd like to see the draft 444 updated soon to better
reflect it's
base on rather tha
a limit in the WSGI spec, with Apache, or just something
with the current version of mod_wsgi?
I know you've proposed many changes to WSGI to fix a lot
of things, and a lot of the discussions seem to be on the
encoding or decoding of headers. But was this ability to
do things like the 100-con
b.REQUEST_ENTITY_TOO_LARGE:
# message too large for server
elif resp.status == httplib.LENGTH_REQUIRED:
# can't do chunked encoding, etc.
Is there in fact some way to do this that I'm missing, and if
not is this something that makes sense to try to fix in
httplib?
--
Deron Meranda
http:
es: ...
Also don't forget about the still-in-draft Link header that is
getting a lot of attention currently (especially at it relates to
resource discovery).
http://tools.ietf.org/id/draft-nottingham-http-link-header-04.txt
It includes IRIs, along
ollow
the RFC strictly; and well, if the posted data doesn't follow the spec we
raise an error along with the original byte string and let the application
deal with it.
An override is I think a reasonable compromise to allow one to
deal with real-world non-conforming browsers; while not throwing
On Tue, Jul 29, 2008 at 3:50 PM, Manlio Perillo
<[EMAIL PROTECTED]> wrote:
> Deron Meranda ha scritto:
>>
>> [...]
>>>
>>> But, at this point, can one consider the content of form post to be
>>> encoded
>>> "text" string?
>>
s provided (or the caller hasn't given an override
default charset); then you must assume US-ASCII. And
you should allow any UnicodeDecodeErrors to bubble
up to the caller. In other words if a user agent sent text
in ISO-8859-x and didn't say it was doing so, then an
error should be raised
any standard, but its the way things seem to work.
I would think it most useful if the decoding framework would strictly
follow the RFC and assume "text/plain; charset=US-ASCII"; but
also allow the caller some means of indicating a different default.
Obviously, if a user agent does provide a
od modules
now; but I have this feeling that an even better one could
be made (I'm talking about the user/caller interface, not
necesarily the internal implementation). I'm playing with some
ideas, and may have some thoughts to share shortly.
--
Deron Meranda
__
On Thu, Mar 20, 2008 at 6:48 PM, John Millikin <[EMAIL PROTECTED]> wrote:
> This is fantastic. My knowledge of other JSON modules was based mainly
> on the comparison page from json.org, and yours is much more complete
> and informative.
Well that's understandable. What's on json.org is great
doing this exercise (although I had the advantage
of fixing mine before anybody could see :)
I assume that will be a really easy fix for you. But, I am using it the
right way though, aren't I?
--
Deron Meranda
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
On Thu, Mar 20, 2008 at 6:03 PM, Bob Ippolito <[EMAIL PROTECTED]> wrote:
> On Thu, Mar 20, 2008 at 1:37 PM, Deron Meranda <[EMAIL PROTECTED]> wrote:
> > I finally sat down and put the five or so top JSON libraries
> > to the test so we can all see what's what.
ded JSON data.
> But I believe that both approaches Alan offers are overkill: he
> proposes something like the db-API, where there are multiple
> implementations of the same API (except in the case of the db-API they
> aren't necessarily 100% interchangeable).
I agr
a derivative of it), I would be
agreeable to a more Pythonic license change.
The big issue I've not yet addressed at this time is Python 3000
support. Mainly because the semantics of dealing with JSON
data necessarily should change to reflect the new bytes typ
14 matches
Mail list logo
