c 7230 3.2.2 permits multiple header fields with the same field name
for all field values defined as comma separated lists, and for
set-cookie.
So you can't feed it straight into dict, unless you place a
requirement on the server to always fold together multiple header
fields with the same field
I'm worried that folk will assume a parallel between ASGI and asyncio,
but there appears to be none... which is only a problem due to the
room for confusion.
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
___
We
sistency.
For consistency, why not a dict unicode -> List[bytes]
?
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
https://m
t of the implementations
of WSGI>
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
https://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
; where the python application is running. And then nothing stop to give the
> socket away to the application and tell to the server to stop to communicate
> with it.
What socket?
Data could be being passed by shm, for instance.
-Rob
--
Robert Collins
Distinguished Technol
thon
> -------
>
> There was an overall positive reaction to introducing *something* that fills
> the WSGI role for applications that use asynchronous Python frameworks.
>
> Exactly how this would look is unclear at this stage, and this should be
> thought of as a long-term goal for this SIG. Amber Brown is clearly working
> on an idea, and we also have Andrew's work on ASGI, either of which could be
> used as a basis for a future PEP.
Guido also had some commentary on this a year or so back, IIRC.
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
https://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
ssion, but please reach out to
> others as well.
>
> I’d really love to come to the end of 2016 with a solid direction for the
> future of web programming in Python. I’m looking forward to working with you
> all on achieving that.
>
> Thanks,
>
> Cory
>
>
> [0]:
with WSGI (e.g. the server-specific
websockets requirements) by making standardisation be predicated on
moving something like Django to a new server core. I recall attempts
to move other big frameworks around years ago now, taking a long long
time I think the question of 'how can we enable i
On 15 October 2014 11:58, Antoine Pitrou wrote:
> On Wed, 15 Oct 2014 11:28:42 +1300
> Robert Collins
> wrote:
>> On 15 October 2014 11:10, Antoine Pitrou wrote:
>>
>> > Each time a connection is accepted, protocol_factory is called without
>> >
r by calling protocol.connection_made(transport)."""
So where would headers etc be supplied to the protocol for reads (and
for outputs)? Since the transport isn't the raw socket, its the bodies
only.
-Rob
--
Robert Collins
Distinguished
ions here: we can have a
WSGI-thing where it looks just a little different to WSGI, or we can
have a pep-3156 Protocol interface. We can share a bunch of logic
either way - e.g. CONTENT_LENGTH etc, but the mechanics of writing
middleware might be quite different.
-Rob
--
Robert Coll
On 15 October 2014 08:41, Antoine Pitrou wrote:
> On Wed, 15 Oct 2014 08:40:05 +1300
> Robert Collins
> wrote:
>> On 15 October 2014 07:30, Antoine Pitrou wrote:
>> > On Tue, 14 Oct 2014 09:47:35 -0700
>> > Guido van Rossum wrote:
>> >>
>>
- its all happening
in C and often in an entirely separate process.
I think it's entirely reasonable to want to write
middleware/frameworks in that context using asyncio, and today there
isn't a defined protocol for doing that.
-Rob
--
Robert Collins
Distinguished Technologist
HP Co
ms, I think we're fine.
Supporting such shims allows frameworks to have their own aesthetic
(e.g. CamelCase vs lower_case) methods, side effects and more.
That said, personally I'd be very open to defining some base classes
nowadays, but only if we have roaring support for that from the
I agree that the protocol doesn't need to make these deployer
decisions etc - but we do need to clarify REMOTE_ADDR for unix
sockets.
I've filed https://github.com/python-web-sig/wsgi-ng/issues/11 to track this.
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
___
specially since HTTP 2 is not yet completely out.
HTTP/2 is in last call stage: it will be entirely finished by the time
we get through whatever process we have here.
What do you want to see changed in the process I'm following?
-Rob
--
Robert Collins
Distinguished Technologist
HP Converg
emember to put
in.
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
https://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
some of) those things. This defeats the
point of WSGI IMNSHO: its not that WSGI is broken or anything, its
just that we're once again writing all our generic middleware in
server-specific fashions. Because the world has moved on and we
haven't.
I think A and C are crucial if we want to re-
On 13 October 2014 16:59, PJ Eby wrote:
> On Sun, Oct 12, 2014 at 6:47 PM, Robert Collins
> wrote:
>> FWIW I'm totally fine with you bringing together that PEP - as you say
>> its complementary to what I'm focused on (I believe I even suggested
>> you might want
On 11 October 2014 01:56, Graham Dumpleton wrote:
I've pushed up
https://github.com/python-web-sig/wsgi-ng/commit/df51d7d6fd4faa4efbe397fda2c323932f967020
which hopefully addresses the process and clarity concerns you
expressed. (If not please help me tweak it appropriately).
-Rob
_
ay
its complementary to what I'm focused on (I believe I even suggested
you might want to do that).
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sig
on has to deal with, then by all means code your version of
> "normalization" into your application. Or write some middleware to do it.
>
> But trying to make "normalization" a part of a WSGI-style specification is
> impossible.
I don't recall proposing that it sh
to
> concretely solve ideas around ASYNC, HTTP/2 and web sockets.
TBH I'd be fine with complaints and wish lists - got to start
somewhere, and having a clear list of the places WSGI has not met
needs would be excellent.
One thing you could do, if you like, is to put a PR together for th
this effort will join me in, and we'll get some
indication together about how well [or otherwise] the basic things
work.
Concurrently, the IETF HTTP wg is now discussing websocket over
HTTP/2, which will provide more data points for the API capabilities
we'll need.
-Rob
--
Robert Col
handler for it to
> complete the request.
>
> As I understand it, wsgi requires me to actually 'return' the response, so I
> don't have the opportunity to call 'yield from', and I do not get access to
> the writer object.
>
> Any suggestions welcome.
On 29 September 2014 08:32, PJ Eby wrote:
> On Sat, Sep 27, 2014 at 5:38 PM, Robert Collins
> wrote:
>> I think we're uncovering important assumptions / facts here.
>
> Indeed!
>
>
>> For clarity: I'm not interested in a nice API for HTTP/2. I want
On 28 September 2014 00:00, Antoine Pitrou wrote:
>
> Hi,
>
> Robert Collins writes:
>>
>> https://github.com/python-web-sig/wsgi-ng/issues/5
>>
>> tl;dr - we don't specify whether read(size) has to return size bytes
>> or just not more than size
mentors will reject such
assistance?
On 28 September 2014 07:55, PJ Eby wrote:
> On Sat, Sep 27, 2014 at 12:20 AM, Robert Collins
> wrote:
>> We should capture these design principles somewhere FAQ-like, since
>> many of the folk participating in this rework weren't part of th
On 27 September 2014 15:44, PJ Eby wrote:
> On Fri, Sep 26, 2014 at 7:41 PM, Robert Collins
> wrote:
>> One thing we could do with the status code in the headers dict is to
>> default to 200 - the vastly common case (in the same way that throwing
>> an error gener
On 27 September 2014 10:31, PJ Eby wrote:
> On Fri, Sep 26, 2014 at 5:02 PM, Robert Collins
> wrote:
>> But perhaps it would be nicer to say:
>> iterator of headers_dict_or_body_bytes
>> With the first item yielded having to be headers (or error thrown),and
>> the l
On 27 September 2014 08:21, Benoit Chesneau wrote:
>
>
> On Fri, Sep 26, 2014 at 5:32 AM, Robert Collins
> wrote:
...
>> So I propose we drop the write callable, and include a queue based
>> implementation in the adapter for PEP- code.
>>
>> -Rob
>>
On 27 September 2014 07:58, PJ Eby wrote:
> On Thu, Sep 25, 2014 at 11:32 PM, Robert Collins
> wrote:
>> So I propose we drop the write callable, and include a queue based
>> implementation in the adapter for PEP- code.
>
> If you're dropping write()
On 26 September 2014 18:16, Dirkjan Ochtman wrote:
> On Fri, Sep 26, 2014 at 6:14 AM, Robert Collins
> wrote:
>> I don't think we need read1 (perhaps I'm wrong) but making read
>> consistent with the io library would be good, I think - particularly
>> for webs
need read1 (perhaps I'm wrong) but making read
consistent with the io library would be good, I think - particularly
for websockets.
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
___
Web-SIG mailing list
Web-SIG@python.or
).
I think making an empty bytestream flush the headers would be
sufficient, and preserve much of the niceness.
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http
ol.
So I propose we drop the write callable, and include a queue based
implementation in the adapter for PEP-3333 code.
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www
WAMPv2. Here are a couple of links
...
Interesting. That looks very similar to Mongrel2.
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
U
ture and who doesn't.
>
> HTH,
>
> --
> Mouad Benchchaoui
>
> ___
> Web-SIG mailing list
> Web-SIG@python.org
> Web SIG: http://www.python.org/sigs/web-sig
> Unsubscribe:
> https://mail.python.org/mailman/options/web-sig/
On 22 September 2014 00:08, Robert Collins wrote:
> On 21 September 2014 16:43, Roberto De Ioris wrote:
>>
>>>
>>> I've proposed using github issues instead of documents; we can
>>> synthesis the issues into prose in the draft docs and reference code
&
On 25 September 2014 07:16, Alan Kennedy wrote:
> [Collin]
>> It seems to me, it is the role of the server/gateway, not the
>> application/framework to determine the "correct" client ip address and
>> correctly account for the situation of being behind a known proxy.
>
> I disagreee. I think it is
don't think we should; but I think we'll deliver a poor result if
we have two different models that folk have to know about for common
case 'I'm just answering a web request' scenarios.
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
at as a basic
deployment feature since it would be useful for microservices
deploying within PAAS environments where a front-end LB of some sort
is a given.
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
https://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
docs and reference code
itself. I think this will be easier to manage than having a dozen
different comment-documents in the repo.
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
___
Web-SIG mailing list
Web-SIG@python.org
Web SI
moderated,
so...
Bill"
- nothing to see here, move right along, and sorry for the noise.
-Rob
On 21 September 2014 10:19, Robert Collins wrote:
> I'm not sure of the right place to bring this up - I tried to on the
> web-sig list itself, but the moderator rejected the post.
>
ard: can we get that changed (or
is there some historical need for it - if so, perhaps we should use
python-dev or some other list) ?"""
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
___
Web-SIG mailing li
On 20 September 2014 19:14, Benoit Chesneau wrote:
> Hi,
>
> I would prefer to have this work being done transparently. If we do it
> rationally it could work imo.
>
> Anyway before thinking to change the protocol or criticizing it maybe we
> could first collect the requirements in HTTP 2 (stream
tions, I've a long history with HTTP (about 14
years now - I joined the Squid project circa 2000), applications that
will benefit from it (horizon, the OpenStack APIs and lmirror), varied
experience deploying WSGI and WSGI derived things, and writing code
both inside frameworks like Django and Zope3
://http2.github.io/http2-spec/index.html#ConnectionErrorHandler)
- backwards compat - making sure that straight PEP- apps still
work well when the server connection is HTTP/2
Is anyone interested in collaborating on an update to WSGI to support
HTTP/2's new features?
-Rob
--
Robert Collins
48 matches
Mail list logo
