several changes

[Tieske]

• cleanup error template
• add redirect method
• add sendFile method (download file) + plugin
• add a TLS plugin

closes #51
closes #36

[EvandroLG]

It's just an amazing contribution! It'll be the perfect release of the Pegasus v1! 👍

[Tieske]

I have a few more changes to make before a 1.0, but it’s shaping up nicely

[EvandroLG]

It looks great @Tieske!
Would you like to add something else to this PR? Otherwise, it seems to me the perfect release of the Pegasus v1!

[Tieske]

preferably I'd like #131 as well in the 1.0 version.

But I'd like your opinion on the following; should the router be a plugin, or should the router replace the handler? Personally I think the latter, since each router-path should probably get its own plugins.

[EvandroLG]

@Tieske IMO it's not the responsibility of the HTTP server to implement the router. Ideally, a framework or plugin should be responsible for a router implementation as it's more of a high-level thing. I'm open to changing my opinion, though :)
Do you remember any server (Python, Node, ngnix, Apache, etc) that natively implements a router logic?

[Tieske]

Lapis is an example.

with a router you typically want specific plugins on specific paths. Eg.

• /downloads/... should get a plugin that serves files as downloads
• /static/... should get a plugin that serves files as html/text
• /api/... should have plugins for content negotiation (if I request /api/user/evandrolg I might want to serve JSON if requested by an app, or an html-div if by a browser)
• all of the above should probably have the "compression" plugin

Now how would this work if the router itself is a plugin?

If the router is implemented in the handler, then it could simply default to a route "/" with the "files" plugin first, and a callback as fallback. That would retain the current handler functionality.

[EvandroLG]

@Tieske IMO Lapis is not the best example, as they are not an HTTP server but a web framework.
Of course, a web framework like Lapis, Rails or Django should implement its router solution, but I don't see good reasons to have it as a native feature of an HTTP server like Pegasus. IMO, The responsibility of an HTTP server is to implement the server part of the HTTP and HTTPS protocols.

[Tieske]

The responsibility of an HTTP server is to implement the server part of the HTTP and HTTPS protocols.

Good point.

So that means that a router should be either an additional handler implementation (instead of a replacement) within the pegasus project, or a separate project altogether (an external "handler" override).

Would the former be acceptable; a second "handler" implementing a router? if not, how did you envision #50 to be implemented?

[EvandroLG]

@Tieske I think we could make it available as part of the plugin structure of Pegasus. WDYT? Would you happen to have any other suggestions for it?

[Tieske]

can you elaborate on what you mean by "we could make it available as part of the plugin structure of Pegasus"?

[EvandroLG]

LGTM :)

[EvandroLG]

@Tieske, let's move the discussion about the Router to the proper PR.
Thanks again! :)