Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

No Content-Type header when returning a stream #3891

Closed
sholladay opened this issue Nov 29, 2018 · 2 comments
Closed

No Content-Type header when returning a stream #3891

sholladay opened this issue Nov 29, 2018 · 2 comments
Assignees
@hueniverse
Labels
bug Bug or defect
Milestone
18.0.0

Comments

@sholladay
Copy link

What are you trying to achieve or the steps to reproduce?

Trying to respond with a stream and receive an appropriate content-type header on the client.

Under most circumstances, hapi sends a content-type header automatically based on whatever the return value of my handler is. However, if the handler returns a stream, this doesn't happen.

Here is a reproducible example that shows no content-type header being sent for a simple "Hello, world!" stream. The response headers are logged to the server's console when starting the server and also rendered in the browser if you visit /.

Edit o5wlywl7pz

Source code 
"use strict";

const hapi = require("hapi");
const { Readable } = require("stream");

const server = hapi.server({ port: 8000 });
server.route({
  method: "GET",
  path: "/hello",
  handler() {
    const stream = new Readable({
      read() {
        this.push("Hello, world!");
        this.push(null);
      }
    });

    return stream;
  }
});

server.route({
  method: "GET",
  path: "/{anything*}",
  handler() {
    return `
      <html><script>
        fetch('/hello').then((response) => {
          const headers = Object.assign(...Array.from(response.headers, ([key, value]) => {
            return { [key]: value };
          }));
          const pre = document.createElement('pre');
          pre.textContent = JSON.stringify(headers, null, 4);
          document.body.appendChild(pre);
        });
      </script></html>
    `;
  }
});

server.inject("/hello").then(response => {
  console.log(JSON.stringify(response.headers, null, 4));
});

server.start();

What was the result you received?

No content-type header is sent in the response when the handler's return value is a simple "Hello, world!" readable stream.

What did you expect?

I expected hapi to set a content-type header whenever possible.

Ideally, I'd like it to be based on the actual contents of the stream, which could be determined by reading the first few bytes to inspect the magic number (also see the file-type module). But even the generic application/octect-stream would be better than nothing.

Context

  • node version: 8.11.3
  • hapi version: 17.6.0
  • os: macOS 10.13.6
@hueniverse
Copy link
Contributor

hapi is never going to try and guess the content type by peeking at the first few bytes. You can set your own content type when returning a stream using h.response(stream).type('text/html'). I'll look into setting a default value.

@hueniverse hueniverse self-assigned this Jan 6, 2019
@hueniverse hueniverse added request lts Backport for maintained old version and removed lts Backport for maintained old version labels Jan 6, 2019
@hueniverse hueniverse added this to the 18.0.0 milestone Jan 6, 2019
@hueniverse hueniverse added bug Bug or defect and removed request labels Jan 18, 2019
@hueniverse hueniverse mentioned this issue Jan 18, 2019
Closed
@lock
Copy link

lock bot commented Jan 9, 2020

This thread has been automatically locked due to inactivity. Please open a new issue for related bugs or questions following the new issue template instructions.

@lock lock bot locked as resolved and limited conversation to collaborators Jan 9, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@hueniverse hueniverse

Labels
bug Bug or defect
Projects
None yet
Milestone
18.0.0
Development

No branches or pull requests
2 participants
@hueniverse @sholladay