search

testillano / h2agent

C++ HTTP/2 Mock Service which enables mocking HTTP/2 applications (also HTTP/1 supported).
Other
10 stars 0 forks source link

Flexibilize purge procedure #79

Closed testillano closed 1 year ago

testillano commented 1 year ago

Is your feature request related to a problem? Please describe. This is a concenr about purge procedure for both server and client mode. For server, purge is done for a specific key (method, uri), so imagine that you need access to event for another key different than currently processed. If that key was purged, I will have no access. Normally, the key is the same, so we could access previous key events, and then purge our context. To afford this, purge could be more independent: not inferred by outState=purge, but actively requested, for example: Define the event:

"source":"purge", "target":"serverEvent.requestMethod=POST&requestUri=/foo/bar&eventNumber=-1",

(or without event number to remove everything)

or

"source":"purge", "target":"clientEvent.clientEndpoint=myendpoint&requestMethod=POST&requestUri=/foo/bar&eventNumber=-1",

No way to purge current context with this method, but last of the test chain can use outState=purge to avoid storage. So, this procedure only works to purge data with different URI than current provision (if it is the same, it is more intuitive to use purge state).

The important thing is that we could configure the event addressing with a key different than the one for which the provision is executed.

Source "purge" could be called "erase" reusing such action, so when target is of kind "event" we know it is a "purge".

testillano commented 1 year ago

KEEP outState=purge procedure to be BACKWARD COMPATIBLE IN THIS CASE, but also permits this new way to proceed.