Details
-
Type:
Improvement Request
-
Status:
Resolved
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 1.0.1-BC
-
Fix Version/s: 1.1.0-BC
-
Component/s: Provider mode
-
Security Level: Public
-
- Environment:
- -
Issue Links
| Depends | |||
|---|---|---|---|
|
|
|
||
Activity
| Field | Original Value | New Value |
|---|---|---|
| Status | New [ 10000 ] | Open [ 10002 ] |
| Priority | Major [ 3 ] | |
| Assignee | Christophe DENEUX [ cdeneux ] | Victor NOËL [ vnoel ] |
| Status | Open [ 10002 ] | In Progress [ 10003 ] |
| Status | In Progress [ 10003 ] | Resolved [ 10004 ] |
| Fix Version/s | 1.1.0 [ 10696 ] | |
| Resolution | Fixed [ 1 ] |
| Status | Resolved [ 10004 ] | Open [ 10002 ] |
| Resolution | Fixed [ 1 ] |
| Description |
When receiving an answer to an HTTP Request, depending on the code, it is possible to define a transformation to apply to the returned content.
Currently, 2XX responses can't use this facility. The desired behaviour is: * If there is no on-http-status configuration ** 2XX: normal response (done for InOnly and RobustInOnly, and response content as Out for InOut and InOptOut) ** Error for all other HTTP Code (with the error and the reason in the message) * If there is an on-http-status configuration, simply apply it to the content as before |
On provider side, now the HTTP codes different from 20x are transformed into JBI errors. We should be able to generate fault on HTTP codes that have such a meaning.
When receiving an answer to an HTTP Request, depending on the code, it is possible to define a transformation to apply to the returned content. {code:xml} <rest:mapping> ... <rest:operation name="ged:consulter"> ... <rest:on-http-status code="404"> <rest:xsl as-fault="true">404.xsl</rest:xsl> </rest:on-http-status> ... </rest:operation> ... </rest:mapping> {code} Where: * {{on-http-status}} defines the processing to apply when the HTTP code given by the attribute '{{code}}' is returned, * {{xsl}} defines the XSL to execute on the given HTTP code. The XSL transformation result will be returned as fault or normal response according to the attribute '{{as-fault}}'. Note: * for MEP '{{RobustInOnly}}', the XSL transformation result will be returned as fault only because the pattern does not support normal response. A warning will be logged if the configuration defines to generate a normal response. * for MEP '{{InOnly}}', no XSL transformation is needed. When receiving a HTTP code different from 20x, if a configuration '{{on-http-status}}' exists for it, the status {{DONE}} will be returned, otherwise the status {{ERROR}}. * |
| Description |
On provider side, now the HTTP codes different from 20x are transformed into JBI errors. We should be able to generate fault on HTTP codes that have such a meaning.
When receiving an answer to an HTTP Request, depending on the code, it is possible to define a transformation to apply to the returned content. {code:xml} <rest:mapping> ... <rest:operation name="ged:consulter"> ... <rest:on-http-status code="404"> <rest:xsl as-fault="true">404.xsl</rest:xsl> </rest:on-http-status> ... </rest:operation> ... </rest:mapping> {code} Where: * {{on-http-status}} defines the processing to apply when the HTTP code given by the attribute '{{code}}' is returned, * {{xsl}} defines the XSL to execute on the given HTTP code. The XSL transformation result will be returned as fault or normal response according to the attribute '{{as-fault}}'. Note: * for MEP '{{RobustInOnly}}', the XSL transformation result will be returned as fault only because the pattern does not support normal response. A warning will be logged if the configuration defines to generate a normal response. * for MEP '{{InOnly}}', no XSL transformation is needed. When receiving a HTTP code different from 20x, if a configuration '{{on-http-status}}' exists for it, the status {{DONE}} will be returned, otherwise the status {{ERROR}}. * |
On provider side, now the HTTP codes different from 20x are transformed into JBI errors. We should be able to generate fault on HTTP codes that have such a meaning.
When receiving an answer to an HTTP Request, depending on the code, it is possible to define a transformation to apply to the returned content. {code:xml} <rest:mapping> ... <rest:operation name="ged:consulter"> ... <rest:on-http-status code="404"> <rest:xsl as-fault="true">404.xsl</rest:xsl> </rest:on-http-status> ... </rest:operation> ... </rest:mapping> {code} Where: * {{on-http-status}} defines the processing to apply when the HTTP code given by the attribute '{{code}}' is returned, * {{xsl}} defines the XSL to execute on the given HTTP code. The XSL transformation result will be returned as fault or normal response according to the attribute '{{as-fault}}', * Note: ** for MEP '{{RobustInOnly}}', the XSL transformation result will be returned as fault only because the pattern does not support normal response. A warning will be logged if the configuration defines to generate a normal response. ** for MEP '{{InOnly}}', no XSL transformation is needed. When receiving a HTTP code different from 20x, if a configuration '{{on-http-status}}' exists for it, the status {{DONE}} will be returned, otherwise the status {{ERROR}}. If there is no '{{on-http-status}}' configuration * 2XX: normal response (status DONE for InOnly and RobustInOnly, and response content as Out for InOut and InOptOut) * Error for all other HTTP Code (with the error and the reason in the message) |
| Summary | Generalize on-http-status transformation to all HTTP Code | We should be able to generate fault on HTTP codes different from 20x |
| Description |
On provider side, now the HTTP codes different from 20x are transformed into JBI errors. We should be able to generate fault on HTTP codes that have such a meaning.
When receiving an answer to an HTTP Request, depending on the code, it is possible to define a transformation to apply to the returned content. {code:xml} <rest:mapping> ... <rest:operation name="ged:consulter"> ... <rest:on-http-status code="404"> <rest:xsl as-fault="true">404.xsl</rest:xsl> </rest:on-http-status> ... </rest:operation> ... </rest:mapping> {code} Where: * {{on-http-status}} defines the processing to apply when the HTTP code given by the attribute '{{code}}' is returned, * {{xsl}} defines the XSL to execute on the given HTTP code. The XSL transformation result will be returned as fault or normal response according to the attribute '{{as-fault}}', * Note: ** for MEP '{{RobustInOnly}}', the XSL transformation result will be returned as fault only because the pattern does not support normal response. A warning will be logged if the configuration defines to generate a normal response. ** for MEP '{{InOnly}}', no XSL transformation is needed. When receiving a HTTP code different from 20x, if a configuration '{{on-http-status}}' exists for it, the status {{DONE}} will be returned, otherwise the status {{ERROR}}. If there is no '{{on-http-status}}' configuration * 2XX: normal response (status DONE for InOnly and RobustInOnly, and response content as Out for InOut and InOptOut) * Error for all other HTTP Code (with the error and the reason in the message) |
On provider side, now the HTTP codes different from 20x are transformed into JBI errors. We should be able to generate fault on HTTP codes that have such a meaning.
When receiving an answer to an HTTP Request, depending on the code, it is possible to define a transformation to apply to the returned content. {code:xml} <rest:mapping> ... <rest:operation name="ged:consulter"> ... <rest:on-http-status code="404"> <rest:xsl as-fault="true">404.xsl</rest:xsl> </rest:on-http-status> ... </rest:operation> ... </rest:mapping> {code} Where: * {{on-http-status}} defines the processing to apply when the HTTP code given by the attribute '{{code}}' is returned, * {{xsl}} defines the XSL to execute on the given HTTP code. The XSL transformation result will be returned as fault or normal response according to the attribute '{{as-fault}}', * Note: ** for MEP '{{RobustInOnly}}', the XSL transformation result will be returned as fault only because the pattern does not support normal response. A warning will be logged if the configuration defines to generate a normal response. ** for MEP '{{InOnly}}', no XSL transformation is needed. When receiving a HTTP code different from 20x, if a configuration '{{on-http-status}}' exists for it, the status {{DONE}} will be returned, otherwise the status {{ERROR}}. If there is no '{{on-http-status}}' configuration: * 2XX: normal response (status DONE for InOnly and RobustInOnly, and response content as Out for InOut and InOptOut) * Error for all other HTTP Code (with the error and the reason in the message) |
| Link |
This issue blocks |
| Status | Open [ 10002 ] | In Progress [ 10003 ] |
| Status | In Progress [ 10003 ] | Resolved [ 10004 ] |
| Resolution | Fixed [ 1 ] |