Support for compressed body POST/PUT media types about xoom-http

[bwehrle]

Ah, I only addressed the request part so far. There should be some kind of raw Response. This Response needs to avoid the serializer based on its type (like the request part done so far).

I don't like the name Binary, since technically the content type header defines that format of the content, and you could do this to receive just raw data.

I can work this one out this week, it's still missing the response feature.

[VaughnVernon]

@bwehrle You named the request body quite well as RequestData. How's about ResponseData for this one?

[bwehrle]

Hi @VaughnVernon
I was reading through the tests and I think the response is well covered already. See:
io.vlingo.xoom.http.resource.RequestHandler0Test#simpleHandlerWithBinaryResponse

  @Test
  public void simpleHandlerWithBinaryResponse() {
    byte[] body = {1, 2, 1, 2};
    final RequestHandler0 handler = new RequestHandler0(Method.GET, "/helloworld")
      .handle(() -> withSuccess(Response.of(Created, Body.from(body, Body.Encoding.None))));
    final Response response = handler.execute(Request.method(Method.GET), logger).outcome();

    assertNotNull(handler);
    assertEquals(Method.GET, handler.method);
    assertEquals("/helloworld", handler.path);
    assertEquals(Body.from(body, Body.Encoding.None).binaryContent(), response.entity.binaryContent());
  }

The Response object lets you specify Body & Headers. I think that's good enough for your use case, because the handler needs to create the compressed body content. Let me know & if its good we can close this issue.

[VaughnVernon]

@bwehrle Answers:

1. I think we must support all three Content-Disposition parameter types, but in particular I need Content-Disposition: attachment; filename="filename.jpg" for my use case
2. I assume binary because that's what a zip format is; if it's not obvious, please expand on your question

FWIW, the zip we are using in this case is going to be tiny because it carries no jars/dlls, etc. Does that change the answer to 2?

I am going based on this SO answer:
https://stackoverflow.com/a/33244623

[bwehrle]

Hi @VaughnVernon ,

Here are my follow-up questions for point 1:

For the receiving function, I think having a single "BinaryRequest" object would be the best approach. Since we cannot deserialize this data (it could be decompressed), we can provide functionality that will work for this new type, which will include the data & meta-data (filename, content encoding).

The resource could work like this:

post.body( BinaryRequest.class ).handle( myRequestHandler )

For question 2:
I think my question wasn't very good; I think the answer is yes, you must get binary data.

Ideally in a future state we'd accept Request body payloads (ie JSON, etc) ALSO with compression. So there are two cases here, and we'll be working on the first one only, and not handling any decompression.

1: Issue#78

• Media Type IS "application" (includes application/x-tar, application/zip or application/x-zip-compressed...)
• Then -> ParameterResolver should produce a BinaryRequestData
• The receiver must handle decompression (since this is typically for files and other resources)

2: Future issue compressed deserializable (JSON) content

• Media Type == JSON
• Content Encoding is one of (gzip,... )
• Then -> ParameterResolver should get decompressed data from a CompressedBody

[VaughnVernon]

@bwehrle Thanks, Brian. I think I may have confused you a bit in the requirements. Let me clarify.

• At this point I am less concerned about the request and more the response.
• Our service will receive a POST with a JSON body, and from that JSON body we will create a zip on the service and respond with it.
• I assumed that we could respond with ObjectResponse of a zip stream inside as long as we can support the media type. Maybe we need a specific ZipResponse type.
• We certainly should also support a request with an attached zip, but that is secondary. I do think that the suggestion you make seems fine: BinaryRequest.class

Did I address everything?

[VaughnVernon]

@bwehrle Excellent, thanks!