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.

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

How to set 'body' on constructed responses #192

Closed
mfalken opened this issue Mar 5, 2014 · 12 comments
Closed

How to set 'body' on constructed responses #192

mfalken opened this issue Mar 5, 2014 · 12 comments
Labels

Comments

@mfalken
Copy link
Member

mfalken commented Mar 5, 2014

The .ts file has a FIXME for this. Is there a plan for what to do?

@jakearchibald
Copy link
Contributor

Clarification:

new Response(obj) currently takes a single param object which is mapped onto properties. However, we haven't specced how to set the body of a response.

@mattto: I've also changed the title of the ticket, let me know if this isn't what you were asking.

@jakearchibald
Copy link
Contributor

The body property on responses is likely to be a stream (https://github.com/whatwg/streams).

How about new Response(body, obj), where body can be:

  • A ReadableStream
  • A Blob - which sets content-length & content-type headers
  • An ArrayBuffer or ArrayBufferView - which sets content-length
  • A string treated as utf8 string body - defaults content-type to text/plain and sets content-length

@alecf
Copy link
Contributor

alecf commented Mar 6, 2014

I like this but it brings up an issue I had doing the prototype - I ran into some conflicts between the body content-type and the headers.. so I'd like to make sure that this works:

r = new Response({headers: {"content-type": "text/html"}}, "<html><body>....</html>");

basically I think we need to think about which content-type overrides which if both headers and the response have a content-type. (Because I wonder if a Blob's content-type should override the header, if the body is a blob, but the other way around for strings? that seems inconsistent though)

@piranna
Copy link

piranna commented Mar 6, 2014

I think the explicit header should override the implicit content-type of the blob/arraybuffer/string

@jakearchibald
Copy link
Contributor

Yeah, that's why I put the body param first, so anything in the options obj would overwrite any defaults determined from the first param

@jakearchibald
Copy link
Contributor

It gets more complicated if you allow .body to be set after construction. Eg:

response.body = "Hello world";
// is response.body still a Stream, but for the content "Hello world"?
// Does it change the content header to text/plain?

@piranna
Copy link

piranna commented Mar 6, 2014

response.body = "Hello world";
// is response.body still a Stream, but for the content "Hello world"?
// Does it change the content header to text/plain?

Changing the content header I would see it as a side effect, so I would
remain the asigned one, if any. Maybe a good way is having
response.contentType = undefined by default, and if so take the content
type of the body object (in that case "text/plain", but for a blob the
content type of the blob object).

@jakearchibald
Copy link
Contributor

Any objection to new Response(body, opts), where body can be:

  • A valid unopened readable stream
  • A Blob - which sets content-length & content-type headers
  • An ArrayBuffer or ArrayBufferView - which sets content-length
  • A string treated as utf8 string body - which sets content-length

Setting .body would do the same as above.

This is similar to the previous proposal, except text no longer sets content-type.

@annevk
Copy link
Member

annevk commented Apr 17, 2014

Do we want to mimic new Request()?

@jakearchibald
Copy link
Contributor

We should support FormData as the body too (more useful for Request). That'd set content-length & content-type.

@annevk
Copy link
Member

annevk commented Jun 6, 2014

Okay, setting body does not work. But you can set it through the constructor and then retrieve it through body.to(). See http://fetch.spec.whatwg.org/#response-class

@annevk annevk closed this as completed Jun 6, 2014
@KenjiBaheux
Copy link
Collaborator

http://crbug.com/411743 and http://crbug.com/410196 should be covering the latest here for Blink.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

6 participants