Hi Benson, all
At the moment the in CORS filter returns 'null' during a preflight
check, whenever some check fails, which means that most likely an HTTP
status code will be returned to do with failure at the selection
algorithm stage, but that status code may not necessarily to be the one
On Mon, Dec 5, 2011 at 7:15 AM, Sergey Beryozkin sberyoz...@gmail.com wrote:
Hi Benson, all
At the moment the in CORS filter returns 'null' during a preflight check,
whenever some check fails, which means that most likely an HTTP status code
will be returned to do with failure at the
On 05/12/11 13:23, Benson Margulies wrote:
On Mon, Dec 5, 2011 at 7:15 AM, Sergey Beryozkinsberyoz...@gmail.com wrote:
Hi Benson, all
At the moment the in CORS filter returns 'null' during a preflight check,
whenever some check fails, which means that most likely an HTTP status code
will be
On Mon, Dec 5, 2011 at 10:15 AM, Sergey Beryozkin sberyoz...@gmail.com wrote:
On 05/12/11 13:23, Benson Margulies wrote:
On Mon, Dec 5, 2011 at 7:15 AM, Sergey Beryozkinsberyoz...@gmail.com
wrote:
Hi Benson, all
At the moment the in CORS filter returns 'null' during a preflight check,
Hi
On 05/12/11 15:15, Sergey Beryozkin wrote:
On 05/12/11 13:23, Benson Margulies wrote:
On Mon, Dec 5, 2011 at 7:15 AM, Sergey Beryozkinsberyoz...@gmail.com
wrote:
Hi Benson, all
At the moment the in CORS filter returns 'null' during a preflight
check,
whenever some check fails, which means
Hi
On 05/12/11 15:39, Benson Margulies wrote:
On Mon, Dec 5, 2011 at 10:15 AM, Sergey Beryozkinsberyoz...@gmail.com wrote:
On 05/12/11 13:23, Benson Margulies wrote:
On Mon, Dec 5, 2011 at 7:15 AM, Sergey Beryozkinsberyoz...@gmail.com
wrote:
Hi Benson, all
At the moment the in CORS
The filter returns Response.ok().build() in the end of the preflight
check,
which indeed will let the out CORS filter to finalize the preflight
response
but in cases where the preflight check was not good then I believe a
random
HTTP error status will be returned depending on where the selection
On 05/12/11 16:00, Benson Margulies wrote:
On Mon, Dec 5, 2011 at 10:42 AM, Sergey Beryozkinsberyoz...@gmail.com wrote:
Hi
On 05/12/11 15:15, Sergey Beryozkin wrote:
On 05/12/11 13:23, Benson Margulies wrote:
On Mon, Dec 5, 2011 at 7:15 AM, Sergey Beryozkinsberyoz...@gmail.com
wrote:
Hi
At some point, we're going to need to try some experiments with a
browser and make sure that whatever it is we've done actually works.
Unfortunately, htmlunit doesn't have this client side yet (I'm working
on a patch). I suppose I should read the source of Chromium or
something, unless you beat me
I translate Anne's answer just now as follows:
To return information to the client, it has to be 2xx. So in the
success case, it has to be 2xx. If it fails, we can do whatever we
prefer: 2xx and no CORS headers or 4xx. I'm with you on a 4xx.
I kind of did a little audit this morning to try and figure out how hard it
will be to split the big bundle into little bundles to allow for smaller OSGi
footprints and such by just loading the desired functionality into OSGi
instead of the entire big bundle (and all it's deps).
At this
Big +1 from me on this (obviously). The fragment approach seems like a
sensible idea to me as a migration strategy.
WRT to changing packages, if you are really worried about backward
compatibility but would like to refactor the split packages out you
*could* consider renaming the package and
On Monday, December 05, 2011 7:21:59 PM David Bosschaert wrote:
Big +1 from me on this (obviously). The fragment approach seems like a
sensible idea to me as a migration strategy.
Another approach COULD be to create a cxf-core (not cxf-rt-core) bundle that
is a shade/bundle of the 3 (or 4 if
13 matches
Mail list logo
