[Apiman-user] How to configure CORS in APIMan? Problems with Headers in ajax

Marc Savy marc.savy at redhat.com
Tue Jan 3 14:03:31 EST 2017


Replying to list.


This going to help me a lot! I'm still planning to update my apiman
> instance. Could I just remove my old version (1.2.3) and then deploy the
> new one with my configurations files?


Yes, that should work fine. You might want to build from master,
considering the bug you encountered. I'll see if it's possible to at least
do a snapshot release soon. People are on holiday at the moment.

How to avoid chunked encoding when the rest api is passing through APIMan?
> <http://stackoverflow.com/questions/41385736/how-to-avoid-chunked-encoding-when-the-rest-api-is-passing-through-apiman>


At present we use chunked encoding[1] because it's much simpler when
handling mutable streaming payloads - especially if we're doing a
transformation where it is not be clear what the final payload size will be
until the process is completed (which would cause substantial buffering).

That being said, in the case of a pipeline where no body mutation policies
exist, we could consider setting content-length. I'll have to think about
it to consider whether there are any important implications. This would be
a feature request.

How to consume a service with chunked-encoding transfer in java using
> Jersey Framework
> <http://stackoverflow.com/questions/41432329/how-to-consume-a-service-with-chunked-encoding-transfer-in-java-using-jersey-fra>


Chunked encoding has been supported since HTTP/1.1, unless you are using an
extremely old/buggy version of Jersey it should work fine. It should be
pretty much transparent in practice.

Your bug might be something else. I suggest trying the latest release and
then filing a JIRA with full information (e.g. expected vs actual; console
output; configuration).

Maybe this is happen for that reason -> APIMAN 984
> <https://issues.jboss.org/browse/APIMAN-984>
>

I don't think you are using the policy mentioned in that ticket, are you?

For now, I do not found any ways to workaround that issue, so I think I'm
> gonna create a policy / plugin to solve that, just to adding a response
> header setting the Content-Length on header. I don't know if it is a good
> idea, but maybe could solve this for while.
>

You may be able to do that, but it would require buffering which will
reduce performance. It may also be tricky to determine from within the
policy which is the final chunk of a stream (with small payloads it's
likely just 1 chunk, though).

On 2 January 2017 at 22:12, Celso Agra <celso.agra at gmail.com> wrote:

> Thanks Marc!
>
> This going to help me a lot! I'm still planning to update my apiman
> instance. Could I just remove my old version (1.2.3) and then deploy the
> new one with my configurations files?
>

> Just to let you know... I believe I got another issue with apiman:
>
>    - How to avoid chunked encoding when the rest api is passing through
>    APIMan?
>    <http://stackoverflow.com/questions/41385736/how-to-avoid-chunked-encoding-when-the-rest-api-is-passing-through-apiman>
>    - How to consume a service with chunked-encoding transfer in java
>    using Jersey Framework
>    <http://stackoverflow.com/questions/41432329/how-to-consume-a-service-with-chunked-encoding-transfer-in-java-using-jersey-fra>
>
> Maybe this is happen for that reason -> APIMAN 984
> <https://issues.jboss.org/browse/APIMAN-984>
>
For now, I do not found any ways to workaround that issue, so I think I'm
> gonna create a policy / plugin to solve that, just to adding a response
> header setting the Content-Length on header. I don't know if it is a good
> idea, but maybe could solve this for while.
>

> Thanks for your help Marc!
>
>
> 2017-01-02 17:04 GMT-03:00 Marc Savy <marc.savy at redhat.com>:
>
>> I addressed this for Celso over JIRA.
>>
>> Summary:
>>
>> - In general, if you're using CORS you should probably use the query
>> parameter to transmit your access token (if you have one). This is because
>> of a limitation to CORS preflight request phase which never transmits
>> custom headers.
>>
>> - A separate issue was a bug (now fixed on master) where a data structure
>> would cause certain header-value fields to be mixed up in specific
>> circumstances.
>>
>> On 28 December 2016 at 14:10, Celso Agra <celso.agra at gmail.com> wrote:
>>
>>> Hi all,
>>>
>>> It's me again!
>>> So, I was looking for some solutions about my issue, and I found this:
>>> https://issues.jboss.org/browse/APIMAN-516
>>>
>>> It seems this issue still occurs with me. I tries to send some headers
>>> via ajax, and get this response:
>>>
>>>> XMLHttpRequest cannot load https://apiman.url. Response to preflight
>>>> request doesn't pass access control check: No 'Access-Control-Allow-Origin'
>>>> header is present on the requested resource. Origin '
>>>> http://192.168.56.22:8080' is therefore not allowed access. The
>>>> response had HTTP status code 500.
>>>
>>>
>>> Here is the Response Headers:
>>>
>>>> Connection:close
>>>> Content-Type:application/json
>>>> Date:Wed, 28 Dec 2016 13:54:08 GMT
>>>> Server:Apache/2.4.18 (Ubuntu)
>>>> Transfer-Encoding:chunked
>>>> X-Gateway-Error:API not public.
>>>> X-Powered-By:Undertow/1
>>>
>>>
>>> and
>>>
>>> Here is the Request Headers:
>>>
>>>> Accept:*/*
>>>> Accept-Encoding:gzip, deflate, sdch, br
>>>> Accept-Language:pt-BR,pt;q=0.8,en-US;q=0.6,en;q=0.4
>>>> Access-Control-Request-Headers:authorization, x-api-key
>>>> Access-Control-Request-Method:GET
>>>> Connection:keep-alive
>>>> Host: apiman.url
>>>> Origin:http://192.168.56.22:8080
>>>> Referer:http://192.168.56.22:8080/app
>>>> User-Agent:Mozilla/5.0 ...
>>>> Query String Parameters
>>>> view source
>>>> view URL encoded
>>>
>>>
>>> Does anyone has the same problem?
>>>
>>> Best regards,
>>>
>>> --
>>> ---
>>> *Celso Agra*
>>>
>>> _______________________________________________
>>> Apiman-user mailing list
>>> Apiman-user at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>>
>>>
>>
>
>
> --
> ---
> *Celso Agra*
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170103/d7ed65be/attachment-0001.html 


More information about the Apiman-user mailing list