Webapp/Express framework support

[edemaine]

Regarding the Future bullet you have in the README:

• Add support for Express and other frameworks

I'm looking to integrate CalDAV into a Meteor server, which uses the webapp framework. I believe webapp was the basis for Express and they're mostly compatible, but I'm not familiar with Koa.

Do you have a sense of how difficult it would be to port? I assume it's mostly src/koa.js that needs to change. I've only taken a quick look, but it looks fairly straightforward. For example:

      ctx.status = 401;
      ctx.response.set('WWW-Authenticate', `Basic realm="${opts.authRealm}"`);

would probably change to

      res.writeHead(401, {
        'WWW-Authenticate': `Basic realm="${opts.authRealm}"`
      });

[sedenardi]

Hi there, apologies for the long delay.

The Koa framework works by essentially wrapping the underlying Node.js IncomingMessage and ServerResponse objects in a ctx variable that's passed throughout the middleware during a particular request. This library isn't doing anything particularly novel that can't be easily extended to other web frameworks (or just a regular Node.js http server):

• parsing the request URL, method, body, and headers
• setting the response body and headers

The biggest difference between operating on the raw req and res objects throughout this library is that we take advantage of the Koa context state to pass information between methods during the lifetime of a single request. In particular, we use ctx.state for things like

• Setting the CalDAV URLs for the request, such as principal and calendar URLs
• Setting the parsed URL parameters
• Setting the authenticated user from the application

To extend this library for use in other frameworks, it'd involve refactoring all the uses of ctx to either

A) operate on the raw req and res objects, or
B) create a framework-agnostic object that each web framework populates based on its own API, is populated by the functions in the library, and is finally passed back to the web framework to set the response values

Option B is probably preferable since we'd then be able to pass arbitrary information throughout the library, basically emulating the Koa context state behavior.

[bas080]

I would really like to use this package and I'll look into how to separate the HTTP framework specific stuff from the "core" functionality. When the "core" has a clear API it would be easier to create glue code for different HTTP frameworks.

EDIT: So I have noticed that the koa ctx is used consistently throughout the codebase. This might make it possible to stub that instance and have that interact with express equivalents.

These are ctx properties I have found in the codebase. Not all require stubbing.

ctx.body
ctx.get
ctx.method.toLowerCase
ctx.redirect
ctx.req
ctx.request.body
ctx.request.ical
ctx.request.type
ctx.request.type.includes
ctx.request.xml
ctx.request.xml.documentElement.localName
ctx.response.set
ctx.set
ctx.state.caldav
ctx.state.calendarHomeUrl
ctx.state.calendarUrl
ctx.state.params
ctx.state.params.calendarId
ctx.state.params.eventId
ctx.state.params.principalId
ctx.state.principalRootUrl
ctx.state.principalUrl
ctx.state.user
ctx.state.user.principalId
ctx.state.user.principalName
ctx.status
ctx.url
ctx.url.match
ctx.url.toLowerCase

Another idea is to spawn a process with a certain port number and proxy the requests in express to that localhost process. Might be less work to get that working.