The cookie thing was a silly example too, I want to keep it more abstracted:
I am searching to stop the payload as first thing in the request handle. After some random and non sense I/O, I will start to deal with that (or not). Even if I call pause, packets still keep being dispatched for a while (otherwise they will be completely lost), so I need an hack. On Wed, Apr 18, 2012 at 6:25 PM, Mikeal Rogers <[email protected]>wrote: > cookies should be in a cache, if you want to ask about a cookie i'm going > to assume it's in Redis or memcached or something fast and in-memory. > Assuming this will respond in a reasonable amount of time is a good > practice. > > retrieving basic auth and session information should use simple buffering > like this and impose a timeout rather than dealing with writing the > incoming data to disc. > > On Apr 18, 2012, at April 18, 20126:23 PM, Kilian C. wrote: > > I agree, anyway the upload/formidable was an abstract example, nothing > related to what I am doing. > My problem is the I/O before let the payload be accepted. > > I am working around this replacing at runtime the emit, pause, resume > methods of the request object. > I do this in order to buffer flying unlucky packets emitted after that the > request is paused. > I'll share the gist here. > > On Wed, Apr 18, 2012 at 6:14 PM, mscdex <[email protected]> wrote: > >> I'd be weary of buffering a file in memory if you're going to be >> waiting on I/O like a database query for authentication, especially if >> you are not imposing a data/file size limit. >> >> IMHO a better route in that case might be to do what formidable does >> (especially for files), write the data to disk instead and delete if >> it ends up the data is not from an authenticated source. If the >> database ends up responding before the end of the incoming data >> stream, you could also just destroy the connection immediately and >> delete the data saved so far (especially if you are not imposing any >> data/file size limits) instead of sending back an HTTP error after the >> end of the incoming data stream. >> >> -- >> Job Board: http://jobs.nodejs.org/ >> Posting guidelines: >> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines >> You received this message because you are subscribed to the Google >> Groups "nodejs" 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/nodejs?hl=en?hl=en >> > > > -- > Job Board: http://jobs.nodejs.org/ > Posting guidelines: > https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > You received this message because you are subscribed to the Google > Groups "nodejs" 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/nodejs?hl=en?hl=en > > > -- > Job Board: http://jobs.nodejs.org/ > Posting guidelines: > https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > You received this message because you are subscribed to the Google > Groups "nodejs" 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/nodejs?hl=en?hl=en > -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" 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/nodejs?hl=en?hl=en
