sarif — archive

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

From: Laurence Golding
To: [email protected]
Date: Wed, 10 Apr 2019 01:15:00 -0000

I made these changes, produced a change draft, https://github.com/oasis-tcs/sarif-spec/blob/master/Documents/ChangeDrafts/Accepted/sarif-v2.0-issue-362-request-response.docx merged it into the provisional draft, https://github.com/oasis-tcs/sarif-spec/blob/master/Documents/ProvisionalDrafts/sarif-v2.0-csd02-provisional.docx 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: [email protected] <[email protected]> On Behalf Of Larry Golding (Myriad Consulting Inc) Sent: Tuesday, April 9, 2019 2:15 PM To: OASIS SARIF TC Discussion List <[email protected]> Cc: Michael Fanning <[email protected]>; Harleen Kaur Kohli <[email protected]> Subject: [sarif] Issue #362: We need "request" and "response" objects after all Importance: High 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