Hi Pablo, Sorry - didn't know that it's up already.
Another few matters for consideration: - Do we save request (send it to tracking service) if it was invalid? - If we save request that is invalid, how do we know if it's not a security risk? We must not allow test client to access data that was invalid based security validation or logic. Allowing every request to go back to test client (even if's getting it from database) could corrupt the test client structure and application integrity. - What do we do if there was a fatal error within application and the request/response couldn't be sent to the tracking service. - What do we do if the tracking service has problems with writing the data to the database? How should the service handle it? In my point of view, there two things we should accomplish: 1) Test service always gets 'some' kind of feedback, even if the request was corrupted. Simple message 'request corrupted' will do it. 2) Define a set of rules, that the service implementations could use to determine if the message was valid or not (from the security validation point of view). This will protect us from request forgery and strange injection attacks. ps. Language specific client implementations will not protect us. Kind Regards, Maciej Brylka On 15 June 2010 13:40, Pablo Cibraro <pablo.cibr...@tellago.com> wrote: > Hi Maciej, > > Yes, that's the idea, we want to store the whole raw message. Regarding the > storage for this message, we already have a tracking service in place for > that purpose. This is a restful service (In this prototype, we used OData > services for a sake of simplicity) that is currently storing the messages > into a database. > > Regards > Pablo. > > -----Original Message----- > From: Matthew Brylka [mailto:m...@tynenet.co.uk] > Sent: Tuesday, June 15, 2010 5:06 AM > To: stonehenge-dev@incubator.apache.org > Subject: RE: [jira] Commented: (STONEHENGE-121) Proposal for M3 > > Hi Pablo, > > If we plan to save the original header information - I would suggest to save > the whole raw message. > > The only tricky part if to watch out for initial language parsers. For > example PHP does interpret the message before you can output it. > > Another questions pops into my head - where are we going to save it? > Good place would be a tracking/logging service that would manage the > information and put it in a proper repository. > > Kind Regards, > Maciej Brylka > > -----Original Message----- > From: Pablo Cibraro [mailto:pablo.cibr...@tellago.com] > Sent: Friday, May 21, 2010 5:23 AM > To: stonehenge-dev@incubator.apache.org > Subject: RE: [jira] Commented: (STONEHENGE-121) Proposal for M3 > > Thanks Ben. Any feedback that you could give will be very well appreciated!. > Regarding the messages, I was thinking that we should include a way to show > complete messages with the WS-* headers, so the developer can compare the > messages generated between different WS stacks. > > Pablo. > >
