[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: Issue #362: We need "request" and "response" objects after all
|
Ok, sorry for the delay. What I wrote below is correct, and I hope it answers your question. After I wrote it, it occurred to me that there might be a better way to interpret the
index property of (for example) a
request object when that object occurs within
run.requests. After discussion with Michael, he pointed out a potential pitfall in what I was thinking, so we decided not to do it. Larry From: Larry Golding (Myriad Consulting Inc) <v-lgold@microsoft.com>
Katrina, Hold off on reading this please. After I wrote it I realized I might have gotten something important wrong. I will reply back later this afternoon. Thanks, Larry From: sarif@lists.oasis-open.org <sarif@lists.oasis-open.org>
On Behalf Of Larry Golding (Myriad Consulting Inc) Here are some examples. EXAMPLE 1: In this example,
thisObject is an element of theRun.requests. We know what array index itâs at (0) so
thisObject.index isnât required: it
MAY be present. But if itâs present, it had better equal that array index. { # A run object "requests": [ { # A request object: thisObject. "index": 0, # Optional. "protocol": "HTTP", "version": "1.1", "method": "GET", "target": "/some/resource", "headers": { "Host": "www.example.com" }, ... } ], ... } EXAMPLE 2: In this example,
thisObject is not an element of
theRun.Requests. Rather, itâs the value of
theResult.request. And in this example, there is no âcachedâ object. That is, there is no object in
theRun.requests that provides additional information for
thisObject. In fact, in this example,
theRun.requests doesnât exist at all. All the information is inline in
theResult.request. Since there is no cached object for
thisObject, thisObject.index
SHALL NOT be present. { # A run object "results": [ { # A result object. "ruleId": "WEB1001", "request": { # A request object: thisObject. It has no index property. There is no cached object. "protocol": "HTTP", "version": "1.1", "method": "GET", "target": "/some/resource", "headers": { "Host": "www.example.com" }, ... }, ... } ] } EXAMPLE 3: Finally, in this example,
thisObject is again the value of theResult.request, not an element of
theRun.requests. But in this case, there
is a cached object, an element of theRun.requests that provides additional information for
thisObject.
thisObject provides only the target property. Since we need to populate the remaining properties of
thisObject from the cached object,
thisObject.index SHALL be present. { # A run object "requests": [ { # A request object: the cached object. "protocol": "HTTP", "version": "1.1", "method": "GET", "headers": { "Host": "www.example.com" }, ... } ], "results": [ { # A result object. "ruleId": "WEB1001", "request": { # A request object: thisObject. It has an index property... "index": "0", # ... so it can get the missing properties from the cached object. "target": "/some/resource" }, ... } ] } Hope this helps! Larry From: Yekaterina O'Neil <katrina@microfocus.com>
I am also confused by the following: âOtherwise (that is, if
thisObject is not an element of
theRun.requests, and
theRun.requests does contain a cached object for
thisObject), then
index SHALL be present, and its value
SHALL be the array index within theRun.requests of the cached object.â I am confused about what is the difference between thisObject being an element of theRun.requests and theRun.requests containing a cached object for thisObject. Same question applies to other similar sections. k From: Larry Golding (Myriad Consulting Inc) [mailto:v-lgold@microsoft.com]
Web analyzers keep insisting on using our format
😊 From: Yekaterina O'Neil <katrina@microfocus.com>
I still feel like request/response information is outside of the scope of SARIF, but I guess if there is a pressing needâ k From: sarif@lists.oasis-open.org [mailto:sarif@lists.oasis-open.org]
On Behalf Of Larry Golding (Myriad Consulting Inc) I made these changes, produced a change draft, merged it into the provisional draft, and closed the issue. Please let us know ASAP if you have any questions or concerns with this issue.
This is a substantive addition to the format, although as I said below, it is non-breaking, uses design patterns weâve used before, and addresses a pressing need. We came very close to meeting our goal of having all changes merged one week before TC #35. Of the three remaining issues that involve any writing (#266, #323, and #358), two of them are quite small, and one of them (#266) Iâm inclined
to dispense with entirely. I expect to finish #323 and #358 tomorrow. Thanks, Larry From: sarif@lists.oasis-open.org <sarif@lists.oasis-open.org>
On Behalf Of Larry Golding (Myriad Consulting Inc) While writing a converter for a web analysis tool, it became clear to me that using
threadFlow.immutableState to hold web request headers was
not sufficient to meet the needs of these tools. So I filed
Issue #362, âDefined request and response objects.â The issue explains the rationale in more detail, and presents a proposal. The proposal is
non-breaking. It recapitulates the pattern weâve used previously for logical locations and addresses: using
cached objects to reduce repetition of request and response objects, and making requests and responses
externalizable to reduce file size. I am going to produce a change draft and optimistically merge it into the provisional draft. I donât actually think this is a controversial proposal; I just wish I had understood earlier how important it was. My original goal was to have everything merged by end of day Tuesday (today) to give everybody a full week to review the final version. At this point I will miss that goal, but only by about half a day. Despite the seeming size of this
change, itâs quite similar to text Iâve written many times before, so I expect to be done no later than noon tomorrow. Iâll let you know as soon as the draft is available. Thanks, Larry |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]