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

Legacy from 1.0: The http-request needs to be updated #13

Open
xml-project opened this Issue Dec 31, 2016 · 3 comments

Comments

Projects
None yet
4 participants
@xml-project
Copy link

xml-project commented Dec 31, 2016

The http-request response needs to be updated 

This is an aggregation of the discussion on "The http-request response needs to be updated" (Issue 170 of the xproc/1.0-specification)

Opened by: ndw on 2015-06-10, 10:21h

ndw said on 2015-06-10, 10:21h:

The current result is a c:response element with embedded possibly base64 encoded c:body element(s). If the response is multipart, we should probably now produce a sequence. Put the headers in the document-properties? 

On 2015-10-07, 14:27h: ndw added this to the XProc 2.0 LC milestone.

@ndw ndw changed the title Legacy from 1.0: The http-request response needs to be updated Legacy from 1.0: The http-request needs to be updated Sep 6, 2018

@ndw

This comment has been minimized.

Copy link
Collaborator

ndw commented Sep 6, 2018

Follow Adam’s lead from http://expath.github.io/expath-cg/specs/http-client-2/

Probably simplifying the return type for single entity bodies.

@eriksiegel

This comment has been minimized.

Copy link
Contributor

eriksiegel commented Sep 6, 2018

@Gertone is going to draft something

@ndw ndw transferred this issue from xproc/3.0-specification Nov 1, 2018

@ndw

This comment has been minimized.

Copy link
Collaborator

ndw commented Feb 5, 2019

Notes from the 05 Feb 2019 workshop:

  • JSON document as input? Yes, of course. Recursive maps.
  • Allow the 11 current attributes on c:request as options on p:http-request
  • Error if you specify an option in both places and they’re inconsistent
  • Review the http-request work that Adam did for EXPath
  • A simple body that isn’t a c:request is a single c:body
  • A simple body that is a JSON object with a “http-request”
    key with the value “request” is a complex request.
  • If the input is JSON, a detailed response is JSON
  • If the input is XML, a detailed response is XML
  • Change the ‘detailed’ option to take JSON/XML as values
  • Geert observes that he likes the work in EXPath except for
    the fact that the response is always a map, even in the simple
    case.
  • “Where do we say that for URI schemes (such as file: and ftp:)
    where a content type is not provided by the underlying request,
    the content type is implementation-dependent?”
    • If we don’t, we should.
    • Use the same algorithm as p:load/p:document
  • “The requirement to process the external subset comes from
    p:load, we probably don't want to impose that on all
    p:http-request calls. Need a way to control it?”
    • No.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment