Re: [Dev] Regarding the HTTP status code to be used if the response is invalid

[Rajith Roshan]

According to the http spec[1], it says status codes are extensible[2]
unless it preserve it class (for ex: 4xx for client errors). I think we can
define our own status code and add it in our documentation. For ex
cloudflare(reverse proxy) sent 520 when it receives invalid response from
origin server. WDYT?

[1] - https://tools.ietf.org/html/rfc2616

[2] - HTTP status codes are extensible. HTTP applications are not required
   to understand the meaning of all registered status codes, though such
   understanding is obviously desirable. However, applications MUST
   understand the class of any status code, as indicated by the first
   digit, and treat any unrecognized response as being equivalent to the
   x00 status code of that class, with the exception that an
   unrecognized response MUST NOT be cached


On Thu, Jan 17, 2019 at 8:35 AM Sanjeewa Malalgoda 
wrote:

> I do not think 422 is correct for issues with response. Usually 4XX errors
> used to indicate client/request errors. In this case its error or issue
> with backend. And for client it can consider as internal server error as
> well. Or we can indicate content related issue. 5XX response would be
> better. But to be honest i do not have other good suggestion :(
>
> Thanks,
> sanjeewa.
>
> On Wed, Jan 9, 2019 at 8:21 PM Harsha Kumara  wrote:
>
>> +1 we should use 422.
>>
>> [1]
>> https://www.quora.com/Which-HTTP-code-is-best-suited-for-validation-errors-400-or-422
>> [2]
>> https://stackoverflow.com/questions/1959947/whats-an-appropriate-http-status-code-to-return-by-a-rest-api-service-for-a-val
>>
>> On Wed, Jan 9, 2019 at 3:22 PM Uvindra Dias Jayasinha 
>> wrote:
>>
>>> I think 422 is the most appropriate given your use case of validating if
>>> a message matches a given schema. So you can receive a valid JSON or
>>> XML(it's not malformed hence it is not a bad request(400)), but it may not
>>> match with the message schema definition you are matching against.
>>>
>>> The specs dont seem to talk about processing from the perspective of the
>>> response. I guess you can use the same code used for the request.
>>>
>>> On Wed, 9 Jan 2019 at 14:54, Shalki Wenushika 
>>> wrote:
>>>
 Hi all,

 This is related to the mail thread subjected as “[Architecture]API
 schema based request/response validator for Microgateway”. I’m validating
 requests/responses coming to the microgateway and send error messages to
 the client if the request/response is invalid.

 When a client sends a request to the microgateway if the request is
 invalid I’m sending an error message with the HTTP status code
 422(Unprocessable entity) to the client. And also I’m doing the response
 validation. If the response coming from the backend is invalid I send an
 error message to the client. I need to know what will be the most
 appropriate HTTP status code to be included in the error if the response is
 invalid.

 Thank you!

 --

 *Shalki Wenushika*
 *Software Engineering Intern*
 WSO2  (University of Moratuwa)
 *mobile *: *+94 716792399* |   *email *:
 
 wenush...@wso2.com




>>>
>>> --
>>> Regards,
>>> Uvindra
>>>
>>> Mobile: 33962
>>>
>>
>>
>> --
>>
>> *Harsha Kumara*
>>
>> Associate Technical Lead, WSO2 Inc.
>> Mobile: +94775505618
>> Email: hars...@wso2.coim
>> Blog: harshcreationz.blogspot.com
>>
>> GET INTEGRATION AGILE
>> Integration Agility for Digitally Driven Business
>>
>
>
> --
> *Sanjeewa Malalgoda*
> Software Architect | Associate Director, Engineering - WSO2 Inc.
> (m) +94 712933253 | (e) sanje...@wso2.com | (b) Blogger
> , Medium
> 
>
> GET INTEGRATION AGILE 
> Integration Agility for Digitally Driven Business
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>


-- 
*Rajith Roshan* | Senior Software Engineer | WSO2 Inc.
(m) +94-717-064-214 |  (e) raji...@wso2.com 


___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Regarding the HTTP status code to be used if the response is invalid

[Malintha Amarasinghe]

Taking from the RFC:

11.2 .  422
Unprocessable Entity

   The 422 (Unprocessable Entity) status code means the server
   understands the content type of the request entity (hence a
   415(Unsupported Media Type) status code is inappropriate), and *the
   syntax of the request entity is correct *(thus a 400 (Bad Request)
   status code is inappropriate) but was unable to process the contained
   instructions.  For example, this error condition may occur if an XML
   request body contains well-formed (i.e., syntactically correct), but
   semantically erroneous, XML instructions.


Sending a 422 will indicate that the syntax of the request (according to
swagger) is correct. So I also don't think 422 appropriate here.

According to the JAX-RS spec 2.1 Section 7.6 (Bean validation) which is
similar to the one we are doing here suggests returning a 400 [1] so I
think we can use the same here.

[1]
https://download.oracle.com/otn-pub/jcp/jaxrs-2_1-final-spec/jaxrs-2_1-final-spec.pdf


Thanks!


On Thu, Jan 17, 2019 at 1:05 PM Sanjeewa Malalgoda 
wrote:

> I do not think 422 is correct for issues with response. Usually 4XX errors
> used to indicate client/request errors. In this case its error or issue
> with backend. And for client it can consider as internal server error as
> well. Or we can indicate content related issue. 5XX response would be
> better. But to be honest i do not have other good suggestion :(
>
> Thanks,
> sanjeewa.
>
> On Wed, Jan 9, 2019 at 8:21 PM Harsha Kumara  wrote:
>
>> +1 we should use 422.
>>
>> [1]
>> https://www.quora.com/Which-HTTP-code-is-best-suited-for-validation-errors-400-or-422
>> [2]
>> https://stackoverflow.com/questions/1959947/whats-an-appropriate-http-status-code-to-return-by-a-rest-api-service-for-a-val
>>
>> On Wed, Jan 9, 2019 at 3:22 PM Uvindra Dias Jayasinha 
>> wrote:
>>
>>> I think 422 is the most appropriate given your use case of validating if
>>> a message matches a given schema. So you can receive a valid JSON or
>>> XML(it's not malformed hence it is not a bad request(400)), but it may not
>>> match with the message schema definition you are matching against.
>>>
>>> The specs dont seem to talk about processing from the perspective of the
>>> response. I guess you can use the same code used for the request.
>>>
>>> On Wed, 9 Jan 2019 at 14:54, Shalki Wenushika 
>>> wrote:
>>>
 Hi all,

 This is related to the mail thread subjected as “[Architecture]API
 schema based request/response validator for Microgateway”. I’m validating
 requests/responses coming to the microgateway and send error messages to
 the client if the request/response is invalid.

 When a client sends a request to the microgateway if the request is
 invalid I’m sending an error message with the HTTP status code
 422(Unprocessable entity) to the client. And also I’m doing the response
 validation. If the response coming from the backend is invalid I send an
 error message to the client. I need to know what will be the most
 appropriate HTTP status code to be included in the error if the response is
 invalid.

 Thank you!

 --

 *Shalki Wenushika*
 *Software Engineering Intern*
 WSO2  (University of Moratuwa)
 *mobile *: *+94 716792399* |   *email *:
 
 wenush...@wso2.com




>>>
>>> --
>>> Regards,
>>> Uvindra
>>>
>>> Mobile: 33962
>>>
>>
>>
>> --
>>
>> *Harsha Kumara*
>>
>> Associate Technical Lead, WSO2 Inc.
>> Mobile: +94775505618
>> Email: hars...@wso2.coim
>> Blog: harshcreationz.blogspot.com
>>
>> GET INTEGRATION AGILE
>> Integration Agility for Digitally Driven Business
>>
>
>
> --
> *Sanjeewa Malalgoda*
> Software Architect | Associate Director, Engineering - WSO2 Inc.
> (m) +94 712933253 | (e) sanje...@wso2.com | (b) Blogger
> , Medium
> 
>
> GET INTEGRATION AGILE 
> Integration Agility for Digitally Driven Business
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>


-- 
Malintha Amarasinghe
*WSO2, Inc. - lean | enterprise | middleware*
http://wso2.com/

Mobile : +94 712383306
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Need to remove JUnit package import in apacheds-core-annotations module

[Senthalan Kanagalingam]

Hi,

Thank you for your quick response. I am currently working on migrating
without using the core-annotation module.

Yes, we are eager to help to speed up the release process. But as we don't
have much knowledge in the internals of the Apache DS, we highly appreciate
your guidance.

Thanks & Regards

On Wed, Jan 16, 2019 at 8:22 PM Emmanuel Lécharny 
wrote:

>
> On 16/01/2019 13:50, Senthalan Kanagalingam wrote:
> > Hi all,
> >
> > I am from WSO2 Identity and access management team. We are using the
> > Apache Active directory as our embedded LDAP. Note that we are not
> > using all the components of the ApacheDS. Currently, we are trying to
> > update the ApacheDS from 1.5.7 to 2.0.0.AM25. We have faced the
> > following issue,
> >
> > The core-annotations module expects 'org.junit.runner'[1] as the
> > import package.  When I go through the implementation, there is only
> > one usage of this package in the
> > DSAnnotationProcessor.getDirectoryService()[2] method. It has the
> > 'org.junit.runner.Description' as argument and the usage of that
> > method is only in the apacheds-test-framework module. We
> > need the apacheds-core-annotations module as we have used the Factory
> > classes for the customization. But we can't inject the JUnit module to
> > the production run-time. So what will the best option be? Can we
> > change this method's arguments to fix this issue?
>
>
> Core-annotation only purpose is to facilitate tests writing. There is no
> reason to include it in production. Simply put: don't add this
> dependency to your build.
>
>
> >
> > Other than this, we are able to update to ApacheDS 2.0.0.AM25. And can
> > you share the estimated release timeline of 2.0.0?
>
>
> When it's ready ;-)
>
> Ok, you have enough people at WSO2 that are participating to Apache
> projects to know what I mean. I would also suggest you spend some time
> participating to the Directory project, which is lacking committers.
> That would speed up the move top a 2.0.
>
>
> Thanks !
>
>
>

-- 

*Senthalan Kanagalingam*
*Software Engineer - WSO2 Inc.*
*Mobile : +94 (0) 77 18 77 466*

___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] Need to remove JUnit package import in apacheds-core-annotations module

[Senthalan Kanagalingam]

Hi all,

I am from WSO2 Identity and access management team. We are using the Apache
Active directory as our embedded LDAP. Note that we are not using all the
components of the ApacheDS. Currently, we are trying to update the ApacheDS
from 1.5.7 to 2.0.0.AM25. We have faced the following issue,

The core-annotations module expects 'org.junit.runner'[1] as the import
package.  When I go through the implementation, there is only one usage of
this package in the DSAnnotationProcessor.getDirectoryService()[2] method.
It has the 'org.junit.runner.Description' as argument and the usage of that
method is only in the apacheds-test-framework module. We
need the apacheds-core-annotations module as we have used the Factory
classes for the customization. But we can't inject the JUnit module to the
production run-time. So what will the best option be? Can we change this
method's arguments to fix this issue?

Other than this, we are able to update to ApacheDS 2.0.0.AM25. And can you
share the estimated release timeline of 2.0.0?

[1] -
https://github.com/apache/directory-server/blob/c93fbc1c877f708d21f9e33113e489108b259526/core-annotations/pom.xml#L196
[2] -
https://github.com/apache/directory-server/blob/master/core-annotations/src/main/java/org/apache/directory/server/core/factory/DSAnnotationProcessor.java#L321

Thanks and Regards,
Senthalan
-- 

*Senthalan Kanagalingam*
*Software Engineer - WSO2 Inc.*
*Mobile : +94 (0) 77 18 77 466*

___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev