paulbellamy / mango Goto Github PK

Would be nice to have a basic-auth middleware. It should probably accept an 'authenticator' function that verifies a set of credentials? That way it could be very extensible.

From the Readme:

env.Logger().Println("Got a", env.Request().Method, "request for", env.Request().RawURL)

Somewhere last year Request.RawURL was deprecated. See discussion and commit:

https://groups.google.com/forum/?fromgroups=#!topic/golang-nuts/t7YlEOJB0xg
http://code.google.com/p/go/source/detail?r=af3d7d10735c

Request().RequestURI should do the trick.

Please use HMAC instead of doing SHA1 over the concatenation of data and secret to avoid length-extension attacks. Although, the use of gob encoding makes them harder to implement, I think they are still possible.

Thank you!

It would be great to have an Etag / Cache-Control handling middleware.

Symptom: Incorrect data is being served by mango.Static for binary files.

Possible cause: The mango.Body type is a string, so binary bytes are typecast to string in mango.Static.

Possible solution: Change mango.Body type to []byte

I think this will be a great framework If you can provide some more like MVC, ORM. Do you have any plan?

I'm having errors compilings examples folder.

Makefile try to compile silence_middleware and cats_middleware as apps not as libraries.

It might be nice to have a "Test" middleware, where requests could be injected into the app stack, and the responses given extra information about what got called, etc...

Other Thoughts:

• I'm not 100% sure if this is really needed, since we can do: stack.Compile(handler), and then pass that an Env, or do stack.HandlerFunc(handler), and pass that an http.Request.

It would be nice to have a Lint module so that we could validate the environment, and response.

Other Thoughts:

• Will probably be a lot simpler than Rack::Lint, because Go is statically-typed, so we primarily just need to check the HTTP spec is being followed. (i.e. status code is >= 100, content-length matches, etc...)

Would be nice if users could set the cookie expiry in the sessions middleware.

It might be nice to have an Edge-Side Include processing middleware.

For more info on ESIs see: http://en.wikipedia.org/wiki/Edge_Side_Includes

Other Thoughts:

• This may be a bad idea. Maybe we should just leave ESIs to Varnish, and real caching proxies.

It would be nice to have a Cross-Origin Resource Sharing, where the user could define a set of urls and permissions for them.

See here for more info on CORS: http://www.w3.org/TR/cors/
Or here: http://en.wikipedia.org/wiki/Cross-Origin_Resource_Sharing

I presume that these are issues related to newer versions of go:

tobi@i7 ~  $ goinstall github.com/paulbellamy/mango
vgoinstall: === cd /Users/tobi/local/cellar/go/r57.2/src/pkg/github.com/paulbellamy/mango; gomake -f- install
6g  -o _go_.6 jsonp.go logger.go mango.go mime.go routing.go sessions.go show_errors.go static.go 
sessions.go:52: not enough arguments in call to strings.Split
sessions.go:97: env.Request().Cookies undefined (type *Request has no field or method Cookies)
sessions.go:98: typechecking loop
sessions.go:113: cookie.String undefined (type *http.Cookie has no field or method String)
make: *** [_go_.6] Error 1
--- exit status 2
goinstall: installing github.com/paulbellamy/mango: running gomake: exit status 2

see: http://golang.org/doc/devel/release.html#r60

It would be awesome to support drop-in http-caching.

Other Thoughts:

• Will probably want to pass the caching 'stuff' (i.e. how long to cache this for, invalidation, etc...) back from the app via some specific header field (or several)
• In-memory store would be a great first step, but it would be nice to eventually support redis/memcached/etc... for caching across servers.