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

Fri Jan 20 20:42:01 EST 2017

Great!

Thanks, Marc.

2017-01-19 14:43 GMT-03:00 Marc Savy <marc.savy at redhat.com>:

> If you build from master you should be able to see Content-Length now if
> you're not using any body mutating policies.
>
> On 3 January 2017 at 19:41, Celso Agra <celso.agra at gmail.com> wrote:
>
>> Thanks for the reply!
>>
>> I was thinking there is some config to set up in APIMan, but the problem
>> was not there. My backend server is not adding the Content-Length, so the
>> server add Transfer-Encoding as Chunked in the Response-Header (now I
>> understand what's going on!).
>>
>> So, what I do was add the HTTP Header Policy Plugin, and then added
>> "Transfer-Encoding" in the Strip Headers fields, as the image below:
>>
>> 
>>
>> I believe this is not the best thing to do but works for me for while.
>> I'll add the Content-Length in service to solve it!
>>
>> 2017-01-03 16:03 GMT-03:00 Marc Savy <marc.savy at redhat.com>:
>>
>>> 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*
>>>>
>>>
>>>
>>
>>
>> --
>> ---
>> *Celso Agra*
>>
>
>

-- 
---
*Celso Agra*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170120/ef34b7e2/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: apiman images.png
Type: image/png
Size: 17124 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/apiman-user/attachments/20170120/ef34b7e2/attachment-0001.png 