Next in thread → Next in month →

RE: Issue #362: We need "request" and "response" objects after all

From
Laurence Golding <>
Date
2019-04-13T21:19:00+00:00
ID
Thread
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) <>

  Sent:  Thursday, April 11, 2019 1:07 PM
To:  Larry Golding (Myriad Consulting Inc) <>; Yekaterina O'Neil <>; OASIS SARIF TC Discussion List <>
Cc:  Michael Fanning <>; Harleen Kaur Kohli <>
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:
  < 
>
  On Behalf Of  Larry Golding (Myriad Consulting Inc)

Sent:  Thursday, April 11, 2019 12:55 PM
To:  Yekaterina O'Neil <  >; OASIS SARIF TC Discussion List < 
>
Cc:  Michael Fanning <  >; Harleen Kaur Kohli < 
>
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 < 
>

  Sent:  Thursday, April 11, 2019 11:42 AM
To:  Larry Golding (Myriad Consulting Inc) <  >; OASIS SARIF TC Discussion List < 
>
Cc:  Michael Fanning <  >; Harleen Kaur Kohli < 
>
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: ]

  Sent:  Thursday, April 11, 2019 9:28 AM
To:  Yekaterina O'Neil <  >; OASIS SARIF TC Discussion List < 
>
Cc:  Michael Fanning <  >; Harleen Kaur Kohli < 
>
Subject:  RE: Issue #362: We need "request" and "response" objects after all


  Web analyzers keep insisting on using our format
Next in thread → Next in month →