Re: A New HTTP Request Header for Specifying Task Contexts

Thank you for the questions, comments, and suggestions thus far. I have improved the proposal: https://github.com/WICG/proposals/issues/188 .


Best regards,
Adam

________________________________
From: Rory Hewitt <rory.hewitt@gmail.com>
Sent: Monday, November 25, 2024 3:49 PM
To: Adam Sobieski <adamsobieski@hotmail.com>
Cc: Glenn Strauss <gs-lists-ietf-http-wg@gluelogic.com>; ietf-http-wg@w3.org <ietf-http-wg@w3.org>
Subject: Re: A New HTTP Request Header for Specifying Task Contexts

> Using two HTTP request headers.

Or use a single request header, as long as the "path through it or a node within [the BPM]" is defined as not allowing the semi-colon - that would allow you a format of:

Header-Name: p={path};u={url}

On Mon, Nov 25, 2024 at 3:28 PM Adam Sobieski <adamsobieski@hotmail.com<mailto:adamsobieski@hotmail.com>> wrote:
Glenn,
All,

Thank you. I didn't know about those caveats with respect to URI's fragment identifiers in HTTP headers.

Brainstorming, other possibilities for discussion do include:

  1.
Using two HTTP request headers. One could be a URL (without a fragment identifier) which refers to a business process model diagram and the other could represent a path through it or a node within it.
  2.
Using a JSON string as the value of an HTTP request header. In this way, one HTTP request header's value could simultaneously reference a diagram, provide a path through it or a node within it, and provide any other useful data or parameters.

Best regards,
Adam

________________________________
From: Glenn Strauss <gs-lists-ietf-http-wg@gluelogic.com<mailto:gs-lists-ietf-http-wg@gluelogic.com>>
Sent: Monday, November 25, 2024 2:24 PM
To: Adam Sobieski <adamsobieski@hotmail.com<mailto:adamsobieski@hotmail.com>>
Cc: ietf-http-wg@w3.org<mailto:ietf-http-wg@w3.org> <ietf-http-wg@w3.org<mailto:ietf-http-wg@w3.org>>
Subject: Re: A New HTTP Request Header for Specifying Task Contexts

On Mon, Nov 25, 2024 at 07:20:33AM +0000, Adam Sobieski wrote:
> Martin,
> All,
>
> A server providing a context-aware service could recognize a received URL, "https://en.wikiprocess.org/wiki/conducting-scholarly-research.bpmn#searching-for-papers" , e.g., from a lookup table, or, instead, retrieve the URL-addressed resource, in this case a BPMN diagram, "https://en.wikiprocess.org/wiki/conducting-scholarly-research.bpmn" , and utilize the URL's fragment identifier, "#searching-for-papers", to inspect the users' precise position or step in the modelled process.

Adam, your example appears to conflict with
https://www.rfc-editor.org/rfc/rfc9110#name-determining-the-target-reso

second paragraph:
"A URI reference is resolved to its absolute form in order to obtain the "target URI". The target URI excludes the reference's fragment component, if any, since fragment identifiers are reserved for client-side processing ([URI], Section 3.5)."

Some servers discard fragment, if present, early in HTTP request
processing.  Fragments have been used in the past in various attacks
to trick or bypass configurable server-side HTTP processing (string
searching and regexes matching).

Expecting fragment to be passed through by proxies or
to server-side applications is not portable.

Cheers, Glenn