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>
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>
> *Sent:* Monday, November 25, 2024 2:24 PM
> *To:* Adam Sobieski <adamsobieski@hotmail.com>
> *Cc:* ietf-http-wg@w3.org <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
>