headers
David Fraser | 4 Nov 2003 13:14
Gravatar

Re: Random thoughts

Ian Bicking wrote:

> On Nov 3, 2003, at 2:29 PM, Gregory (Grisha) Trubetskoy wrote:
>
>> In case of POST, availability of form data implies that something 
>> consumes
>> (reads) the request. Some people would prefer to read it themselves. A
>> (first) call to form() would trigger this action, after which there
>> wouldn't be anything to read. Otherwise you could read it with
>> request.read().
>
>
> I forget how exactly cgi works right now, Webware has tried to get 
> this right but I'm not sure if it has.  I think it consumes the 
> request body if it's valid data that can be parsed (maybe even in 
> spite of the content-type of the request), but otherwise leaves it 
> intact and sets no fields.
>
> If it is valid data that can be parsed into fields, maybe it's not so 
> bad if the body is lost, because all the information remains.  If you 
> have an option to keep the data, I'd just include it in the 
> constructor -- parsing it lazily (and thus throwing away the body 
> lazily) seems error-prone.  If it can't be parsed into fields, then 
> certainly it should be available in some other form.

However, we should deal with uploaded files differently here - they 
could be huge! You dno't want them read in automatically.

David
(Continue reading)

Permalink | Reply | 4 comments |
headers
Bill Janssen | 4 Nov 2003 20:52
Favicon

Re: Random thoughts

> However, we should deal with uploaded files differently here - they 
> could be huge! You dno't want them read in automatically.

Well, uploaded files appear as data in-line in the request body.  You
have to read them from the connection to clear the request (and
possibly to get to other data which follows the uploaded file).  The
question is whether you want to pass them around as 200-MB strings, or
whether you want to write them to a temp file and pass the file
around.

Bill

_______________________________________________
Web-SIG mailing list
Web-SIG@...
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/gcpw-web-sig%40m.gmane.org
Permalink | Reply | 1 comment |
headers
Thijs van der Vossen | 4 Nov 2003 23:00

Re: Random thoughts

Bill Janssen wrote:
>>However, we should deal with uploaded files differently here - they 
>>could be huge! You dno't want them read in automatically.
> 
> Well, uploaded files appear as data in-line in the request body.  You
> have to read them from the connection to clear the request (and
> possibly to get to other data which follows the uploaded file).  The
> question is whether you want to pass them around as 200-MB strings, or
> whether you want to write them to a temp file and pass the file
> around.

Writing to temp files is probably what you want most of the time, but 
for some applications it can be usefull to directly read the posted file 
from the connection. Examples of this include feeding a event-based 
parser with a large xml file of being able to display an upload 
indicator for (multiple) file uploads.

Regards,
Thijs

--

-- 
Fingertips __ www.fngtps.com __ +31.(0)20.4896540

_______________________________________________
Web-SIG mailing list
Web-SIG@...
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/gcpw-web-sig%40m.gmane.org
(Continue reading)

Permalink | Reply | 0 comments |
headers
John J Lee | 5 Nov 2003 00:48
Picon
Favicon

Re: Client-side support - webunit is back :)

On Wed, 5 Nov 2003, Richard Jones wrote:
[...]
> Heh. It looks like both codebases have been around for about the same time too
> :)
>
> I'll look into changing the name of my codebase.

You're obviously more mature than I am -- I'd end up squabbling over who
should keep the cute name ;-)

John

_______________________________________________
Web-SIG mailing list
Web-SIG@...
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/gcpw-web-sig%40m.gmane.org
Permalink | Reply | 0 comments |
headers
Stuart Bishop | 5 Nov 2003 02:01
Gravatar

Re: Request and Response objects


On 30/10/2003, at 3:31 PM, David Fraser wrote:

> A lot of the arguments for the dual object model are about what you 
> can do with a separate object.
> But these seem to me to miss the point .... you can create your own 
> "response"-type class that holds the *value* of a response, and as 
> many instances of it per request as you want to. But the actual Web 
> API response object is for *writing* the response back to the client. 
> You can only write one response back per request, so it makes sense 
> for them to be the same object.

The "response"-type class is the interesting bit - the API for setting
status codes, headers, cookies etc. And you do want multiples, of
which only one is sent to the client. In particular, if you catch an
exception and are preparing an error message you will want a clean
response to work with rather than, for example, accidently sending
your error message with the wrong content-type. The alternative would
be a reset() method on the response buffer, although this isn't as
flexible.

def handler(request):
	try:
		response = Reponse(request)
		filename = response.request.getFirst('filename')
		response.headers['Content-Type'] = 'image/jpeg'
		response.cookies['latest'] = filename
		response.write(open(filename,'rb').read()) # A filelike object
	except IOError:
		response = Response(request)
(Continue reading)

Permalink | Reply | 10 comments |
headers
Greg Ward | 5 Nov 2003 03:01
Favicon

Re: Random thoughts

On 04 November 2003, David Fraser said:
> However, we should deal with uploaded files differently here - they 
> could be huge! You dno't want them read in automatically.

I'm pretty happy with the solution I came up with for Quixote 0.5.1: a
subclass of HTTPRequest, HTTPUploadRequest, specialized to handle
"multipart/form-data" requests (which are mainly used for uploads, hence
the name of the class).  From upload.py in the Quixote distribution:

class HTTPUploadRequest (HTTPRequest):
    """
    Represents a single HTTP request with Content-Type
    "multipart/form-data", which is used for HTTP uploads.  (It's
    actually possible for any HTML form to specify an encoding type of
    "multipart/form-data", even if there are no file uploads in that
    form.  In that case, you'll still get an HTTPUploadRequest object --
    but since this is a subclass of HTTPRequest, that shouldn't cause
    you any problems.)

    When processing the upload request, any uploaded files are stored
    under a temporary filename in the directory specified by the
    'upload_dir' instance attribute (which is normally set, by
    Publisher, from the UPLOAD_DIR configuration variable).
    HTTPUploadRequest then creates an Upload object which contains the
    various filenames for this upload.

    Other form variables are stored as usual in the 'form' dictionary,
    to be fetched later with get_form_var().  Uploaded files can also be
    accessed via get_form_var(), which returns the Upload object created
    at upload-time, rather than a string.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Greg Ward | 5 Nov 2003 03:03
Favicon

Re: Random thoughts

On 03 November 2003, Gregory (Grisha) Trubetskoy said:
> The problem here is that this would work great for someone who believes in
> separation, but someone who wants these things compbined would need to
> have this line in every bit of code.
> 
> I think the way to do it would be to somehow provide either behaviour
> without additional code, e.g. as an argument to some __init__.
> 
> I also think that the combined should be default,

+1 on the above

> with the query string
> overriding posted data.

Hang on a sec.  I thought everyone agreed that POST data should override
query data.  Am I badly misremembering, or did you have brainfart?

        Greg
--

-- 
Greg Ward <gward@...>                         http://www.gerg.ca/
I appoint you ambassador to Fantasy Island!!!

_______________________________________________
Web-SIG mailing list
Web-SIG@...
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/gcpw-web-sig%40m.gmane.org
(Continue reading)

Permalink | Reply | 2 comments |
headers
Gregory (Grisha) Trubetskoy | 5 Nov 2003 04:09

Re: Random thoughts


On Tue, 4 Nov 2003, Greg Ward wrote:

> On 03 November 2003, Gregory (Grisha) Trubetskoy said:
>
> > with the query string
> > overriding posted data.
>
> Hang on a sec.  I thought everyone agreed that POST data should override
> query data.  Am I badly misremembering, or did you have brainfart?

I've since changed my mind on it (it's in some later post). :-)

My latest position is:

[as opposed to overriding] they get combined in a list [same as multiple
inputs with same name].

I also think that the order of items in the combined list should be
documented as "undefined", i.e. "don't rely on it, dear developer". :-)

Grisha

_______________________________________________
Web-SIG mailing list
Web-SIG@...
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/gcpw-web-sig%40m.gmane.org
(Continue reading)

Permalink | Reply | 1 comment |
headers
David Fraser | 5 Nov 2003 09:49
Gravatar

Re: Random thoughts

Greg Ward wrote:

>On 04 November 2003, David Fraser said:
>  
>
>>However, we should deal with uploaded files differently here - they 
>>could be huge! You dno't want them read in automatically.
>>    
>>
>
>I'm pretty happy with the solution I came up with for Quixote 0.5.1: a
>subclass of HTTPRequest, HTTPUploadRequest, specialized to handle
>"multipart/form-data" requests (which are mainly used for uploads, hence
>the name of the class).  From upload.py in the Quixote distribution:
>
>class HTTPUploadRequest (HTTPRequest):
>    """
>    Represents a single HTTP request with Content-Type
>    "multipart/form-data", which is used for HTTP uploads.  (It's
>    actually possible for any HTML form to specify an encoding type of
>    "multipart/form-data", even if there are no file uploads in that
>    form.  In that case, you'll still get an HTTPUploadRequest object --
>    but since this is a subclass of HTTPRequest, that shouldn't cause
>    you any problems.)
>
>    When processing the upload request, any uploaded files are stored
>    under a temporary filename in the directory specified by the
>    'upload_dir' instance attribute (which is normally set, by
>    Publisher, from the UPLOAD_DIR configuration variable).
>    HTTPUploadRequest then creates an Upload object which contains the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Gregory (Grisha) Trubetskoy | 5 Nov 2003 17:34

Re: Request and Response objects


On Wed, 5 Nov 2003, Stuart Bishop wrote:

> The "response"-type class is the interesting bit - the API for setting
> status codes, headers, cookies etc. And you do want multiples, of
> which only one is sent to the client. In particular, if you catch an
> exception and are preparing an error message you will want a clean
> response to work with rather than, for example, accidently sending
> your error message with the wrong content-type. The alternative would
> be a reset() method on the response buffer, although this isn't as
> flexible.
>
> def handler(request):
> 	try:
> 		response = Reponse(request)
> 		filename = response.request.getFirst('filename')
> 		response.headers['Content-Type'] = 'image/jpeg'
> 		response.cookies['latest'] = filename
> 		response.write(open(filename,'rb').read()) # A filelike object
> 	except IOError:
> 		response = Response(request)
> 		response.status = 404
> 		print >> response, 'File not found'
> 	response.close() # No more data - compute content-length header
> 	response.send() # Send to client.

The functional equivalent of the above would look like this in mod_python.

def handler(req):
(Continue reading)

Permalink | Reply | 9 comments |

Gmane