request / response serialization to message about graft-http HOT 11 CLOSED

I think you should have a ret channel on the request, not the httpResponse. On that ret channel, graft-http will expect what you identified as "response" in your example, and body can be:

1. a string
2. a buffer
3. (default) a stream, in that case it's piped to the httpResponse

Does it make any sense?

from graft-http.

I think we should have the HTTP body parsed for JSON, ecc.. otherwise doing crazy things will be hardish. However we should be able to disable that by turning a flag, or something similar.

from graft-http.

Makes sense!

We can take a look at the content-type of the request and parse the body appropriately. The bridge function can accept a hash of options to disable this, which would just pass the request stream through.

from graft-http.

I'm also assuming that since graft-http will send the message right when the request comes in, the body will still be a stream, even if it is getting parsed as json, form data, etc. You would have to listen for data or end to get the data from the request. Maybe there is an option to wait for the request to be finished before sending the message.

from graft-http.

@tamagokun I'm not sure on that. Otherwise a validation step might be tricky, and that's going to be parsed anyway for doing anything serious.

from graft-http.

Or if we want the body parsed, it will wait until the request is finished before sending the message?

// parse: true
// graft sends message once request stream emits end. contents of body is string or object
graftHttp.use(service(), {parse: true});

from graft-http.

I definitely think so.

from graft-http.

how much of this is going to be re-inventing connect/express though ?

perhaps we should focus on adapting connect middleware to be used?

from graft-http.

Exactly. middleware micro-service. Something that could wrap up a connect middleware into a micro service that is consumable by graft. It would be great to create something that could achieve full interoperability with any http based middleware, but I haven't done any tests yet.

All of the routing and parsing we are discussing could be handled by piping the request through to other graft-compatible middleware rather than using options.

from graft-http.

Converting requests to/from messages: https://github.com/GraftJS/graft-http/blob/draft/lib/request.js

As I mentioned in #1, I need a better way to handle serializing the http request. Middleware and other things love to tack on properties to that and share them with other middleware, so I was imagining a black list of properties that we would throw away, and just keep the rest (plus a few convenience ones that aren't normally a part of http.IncomingMessage)

from graft-http.

This should be all set now. If message keys need to change at all, open a new issue.

from graft-http.