Added getHeader and setHeader to the preload context

[ehrencrona]

Fixes #1354 by adding getHeader (for request headers) and setHeader (for response headers) to the preload context.

A possible argument against this solution is that it allows less flexibility than just exposing the req and res objects directly. Evidence of this would be that there are more header-related functions you might want such as getHeaderNames.

On the other hand I think this covers the vast majority of use cases and gives the user fewer possibilities to screw up.

It's also possible to argue that it's confusing that that getHeader operates on request headers and setHeader on response headers, though, here too, in the vast majority of cases this is what you want. If you want to do anything more complex you should look into middleware.

If the consensus is we should do this differently, I'm happy to change it.

(I also took the opportunity to extract the fetch function used in preload into a different file, since get_page_handler is quite long and hard to overview)

Before submitting the PR, please make sure you do the following

• It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
• This message body should clearly illustrate what problems it solves.
• Ideally, include a test that fails without this PR but passes with it.

Tests

• Run the tests with npm test and lint the project with npm run lint

[Conduitry]

What do getHeader and setHeader do when run during the preload on the client side?

[ehrencrona]

@Conduitry Oh, I was under the impression it's only running on the server side. Ok, back to the drawing board then.

[benmccann]

I've included an idea for this API in a routing RFC that I just opened: sveltejs/rfcs#36

[talltyler]

@benmccann I've read your RFC and looked at the code in @ehrencrona's PR and I'm not sure I'm convinced that this PR should be closed. Why not solve the issue that this code runs in both environments and then call this complete. The this.redirect() function calls code that only makes sense on the server.

res.statusCode = redirect.statusCode;
res.setHeader('Location', location);
res.end();

You can wrap the implementation of these header functions so that the client doesn't break. Being able to set cache-control and other headers like this in this context makes sense to me, sure there might be situations that using a middleware is more ideal for some header types but for the basics doing it in the context of the page you are rendering seems far better than in the router or other disconnected file to the page that you are rendering.