OASIS Open Mailing List Archives  ·  All Lists  ·  sarif  ·  2019-04

sarif — archive

[Date Prev]  |  [Thread Prev]  |  [Thread Next]  |  [Date Next]   —  [Date Index]  |  [Thread Index]  |  [Month Index]  |  [List Home]

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) <[email protected]> Sent: Thursday, April 11, 2019 1:07 PM To: Larry Golding (Myriad Consulting Inc) <[email protected]>; Yekaterina O'Neil <[email protected]>; OASIS SARIF TC Discussion List <[email protected]> Cc: Michael Fanning <[email protected]>; Harleen Kaur Kohli <[email protected]> Subject: RE: Issue #362: We need "request" and "response" objects after all 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: [email protected] < [email protected] > On Behalf Of Larry Golding (Myriad Consulting Inc) Sent: Thursday, April 11, 2019 12:55 PM To: Yekaterina O'Neil < [email protected] >; OASIS SARIF TC Discussion List < [email protected] > Cc: Michael Fanning < [email protected] >; Harleen Kaur Kohli < [email protected] > Subject: [sarif] RE: Issue #362: We need "request" and "response" objects after all 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 < [email protected] > Sent: Thursday, April 11, 2019 11:42 AM To: Larry Golding (Myriad Consulting Inc) < [email protected] >; OASIS SARIF TC Discussion List < [email protected] > Cc: Michael Fanning < [email protected] >; Harleen Kaur Kohli < [email protected] > Subject: RE: Issue #362: We need "request" and "response" objects after all 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:[email protected] ] Sent: Thursday, April 11, 2019 9:28 AM To: Yekaterina O'Neil < [email protected] >; OASIS SARIF TC Discussion List < [email protected] > Cc: Michael Fanning < [email protected] >; Harleen Kaur Kohli < [email protected] > Subject: RE: Issue #362: We need "request" and "response" objects after all Web analyzers keep insisting on using our format

[Date Prev]  |  [Thread Prev]  |  [Thread Next]  |  [Date Next]   —  [Date Index]  |  [Thread Index]  |  [Month Index]  |  [List Home]