I cannot change server to do redirect with 303 or 307.
I'm using Sun JES Identity Server Policy Agent that is integrated to WS as Filter in web.xml depl descriptor. This Filter and code behind do the redirect to another machine but always with 302. After I reach redirected URI (Sun JES Identity Server) it do the authentication and then redirects me back to initial URI (again with 302). After I'm back to initial URI Filter checks authentication cookie that is issued by Identity Server in previous redirect and pass me to resource on that URI if the cookie is present.
As you can see all servers that does redirections are Sun products that I cannot change.
So the only way to solve this problem is if I could somehow set that HTTP connection on client to not automatically redirects requests. In that case when server tries to redirect me I will get exception from which I could see HTTP response code and also redirection Location and make redirection call on my own.
As I said in my previous mail regarding the cookies I find how to access cookies for SOAPMessage context but I'm still missing some get and set methods that will accept domain name and string with all cookies for set method or accept domain name and return string with all cookies in case of get method.
Is it possible to do such changes in JAX-RPC.
I could also send you source code with changes that I made for testing purposes.
BR
Kreso
> -----Original Message-----
> From: Kevin Jones [mailto:kevinj_at_develop.com]
> Sent: 20. rujan 2004 15:28
> To: users_at_jax-rpc.dev.java.net
> Subject: RE: Accessing HTTP Session and Cookies in JAX-RPC
> client (JWSDP
> 1.3)
>
>
> If I understand your problem you are sending an HTTP request
> to a URL that
> is then being re-directed to an HTTPS request with a 302.
>
> It is the server doing the re-direct, and I can think of at least two
> solutions
> i) can you re-confgiure the server to do a 307 (rather than a
> 302/303) so
> that the client then automatically redirects using POST
> rather than GET
> if not then ii) can you write a filter (assuming it's a Java
> server) to
> check for the URL then simply re-direct with the 307 code
> back to the HTTPS
> URL.
>
> Which server are you using?
> Are you using integrated Servlet/JSP authentication? and is
> that why you're
> getting the re-direct?
>
>
> Kevin Jones
> http://kevinj.develop.com
>
>
> > -----Original Message-----
> > From: Kresimir Kers (ZG/ETK) [mailto:kresimir.kers_at_ericsson.com]
> > Sent: 20 September 2004 07:59
> > To: 'users_at_jax-rpc.dev.java.net'
> > Subject: RE: Accessing HTTP Session and Cookies in JAX-RPC
> > client (JWSDP 1.3)
> >
> > Hello,
> >
> > I looked for HTTP response code that I got for redirect and I
> > saw that it is 302 that according to HTTP specification is:
> >
> > 10.3.3 302 Found
> > The requested resource resides temporarily under a different
> > URI. Since the redirection might be altered on occasion, the
> > client SHOULD continue to use the Request-URI for future
> > requests. This response is only cacheable if indicated by a
> > Cache-Control or Expires header field.
> >
> > The temporary URI SHOULD be given by the Location field in
> > the response. Unless the request method was HEAD, the entity
> > of the response SHOULD contain a short hypertext note with a
> > hyperlink to the new URI(s).
> >
> > If the 302 status code is received in response to a request
> > other than GET or HEAD, the user agent MUST NOT automatically
> > redirect the request unless it can be confirmed by the user,
> > since this might change the conditions under which the
> > request was issued.
> >
> > Note: RFC 1945 and RFC 2068 specify that the client is
> > not allowed
> > to change the method on the redirected request. However, most
> > existing user agent implementations treat 302 as if it
> > were a 303
> > response, performing a GET on the Location field-value
> > regardless
> > of the original request method. The status codes 303
> > and 307 have
> > been added for servers that wish to make unambiguously
> > clear which
> > kind of reaction is expected of the client.
> >
> > As it is stated in "Note" it seems that Java HTTP
> > implementation treats 302 as 303 and this does not work with
> > WS because we need "POST" method. I looked a little bit at
> > source code of JAX-RPC RI and found that HttpUrlConnections
> > behaviour regarding redirection is leaved in default state
> > that is it automatically redirects if it receives 3XX HTTP
> > response. There is maybe solution to this problem to allow
> > setting of this behaviour using, for example some property of
> > SOAPMessage context (like it is done for CookieJar). Then I
> > could catch throwed exception and from exception message find
> > out what happened and what HTTP response code I got.
> > BTW, I saw in source that I could access CookieJar that
> > stores all cookies by casting generated stub class for client
> > to StubBase class that generated client stub class extends.
> > To have full control over the cookies I will need some get
> > and set methods on CookieJar class.
> >
> >
> > BR,
> >
> >
> > Kreso
> >
> >
> >
> > > -----Original Message-----
> > > From: Kevin Jones [mailto:kevinj_at_develop.com]
> > > Sent: 15. rujan 2004 10:04
> > > To: users_at_jax-rpc.dev.java.net
> > > Subject: RE: Accessing HTTP Session and Cookies in JAX-RPC client
> > > (JWSDP
> > > 1.3)
> > >
> > >
> > > > Here is explanation of HTTP redirect use case and
> > problems regarding
> > > > it. In cases when you are redirected from one URL to some
> > other and
> > > > if both URLs have the same protocol e.g.
> > > > HTTP then all works fine. If redirection URL has
> > different protocol
> > > > then first URL e.g. first is HTTP and second HTTPS automatic
> > > > redirection does not work (this is maybe a bug).
> > > > Second problem in this use case is that underlying HTTP
> mechanism
> > > > does not redirect to other URL with the same method
> > > > (POST/GET) it always uses GET and this is problem. If I
> > understand
> > > > HTTP specification correct redirection should keep HTTP
> > method so if
> > > > we access some URL with POST method and it redirects us
> > to other URL
> > > > method should remain the same.
> > >
> > > Nope, it depends on the status code. In HTTP 1.1 there are
> > > (essentially) two
> > > status codes that can be sent, a 303 and a 307. The 303
> > says 'redirect
> > > to this URL and *always* use GET, regardless of the
> original verb',
> > > 307 says 'replay the original request to this new location'
> > You need
> > > to trace to see which code is being used. There are also
> some 'down
> > > level'
> > > codes (i.e. codes
> > > defined in previous versions of the spec that are still used for
> > > backwards
> > > compatibility) that you may see, you need to read RFC 2616
> > to see what
> > > these really mean,
> > >
> > > Kevin Jones
> > > http://kevinj.develop.com
> > >
> > >
> > > > -----Original Message-----
> > > > From: Kresimir Kers (ZG/ETK) [mailto:kresimir.kers_at_ericsson.com]
> > > > Sent: 13 September 2004 07:48
> > > > To: 'users_at_jax-rpc.dev.java.net'
> > > > Subject: RE: Accessing HTTP Session and Cookies in
> JAX-RPC client
> > > > (JWSDP 1.3)
> > > >
> > > > OK, then this is something that should be included in
> > JAX-RPC, that
> > > > is, some sort of access to underlying transport protocol
> > whatever it
> > > > is (HTTP, JMS, SMTP ...). I could see use cases for at
> > least two of
> > > > transport protocols: HTTP/S and JMS. In HTTP access to
> > cookies that
> > > > are not JSESSION cookie and perhaps to control HTTP
> > redirection (I
> > > > will explain it
> > > > later) and in JMS to some custom message properties or
> REDELIVER
> > > > flag ...
> > > >
> > > > Here is explanation of HTTP redirect use case and
> > problems regarding
> > > > it. In cases when you are redirected from one URL to some
> > other and
> > > > if both URLs have the same protocol e.g.
> > > > HTTP then all works fine. If redirection URL has
> > different protocol
> > > > then first URL e.g. first is HTTP and second HTTPS automatic
> > > > redirection does not work (this is maybe a bug).
> > > > Second problem in this use case is that underlying HTTP
> mechanism
> > > > does not redirect to other URL with the same method
> > > > (POST/GET) it always uses GET and this is problem. If I
> > understand
> > > > HTTP specification correct redirection should keep HTTP
> > method so if
> > > > we access some URL with POST method and it redirects us
> > to other URL
> > > > method should remain the same.
> > > >
> > > > Another thing is HTTP/S in current implementation Java
> > certificate
> > > > keystore and pass for it are defined through Java system
> > property so
> > > > we must use the same keystore for all connections in that
> > > > application and this is something that can cause problems
> > because we
> > > > might want to have different keystores for client
> connections and
> > > > different for server certificates (security reasons). Access to
> > > > underlying HTTPS protocol will solve this problem.
> > > >
> > > >
> > > >
> > > > Kresimir Kers, B.Sc.E.E. & Comp.
> > > > System/Software Engineer Senior Specialist E-Systems
> > > > Department (ETK/OEP) Ericsson Nikola Tesla d.d. Zagreb, Croatia
> > > > phone: +385 1 365 3911
> > > > mobile: +385 91 365 3911
> > > > fax: +385 1 365 3610
> > > > email: kresimir.kers_at_ericsson.com
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Kevin Jones [mailto:kevinj_at_develop.com]
> > > > > Sent: 11. rujan 2004 11:08
> > > > > To: users_at_jax-rpc.dev.java.net
> > > > > Subject: RE: Accessing HTTP Session and Cookies in
> > JAX-RPC client
> > > > > (JWSDP
> > > > > 1.3)
> > > > >
> > > > >
> > > > > I'm not sure in the SI that there is any way of getting
> > > at the HTTP
> > > > > stream within the client,
> > > > >
> > > > > Kevin Jones
> > > > > http://kevinj.develop.com
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Kresimir Kers (ZG/ETK)
> > [mailto:kresimir.kers_at_ericsson.com]
> > > > > > Sent: 09 September 2004 15:12
> > > > > > To: 'users_at_jax-rpc.dev.java.net'
> > > > > > Subject: RE: Accessing HTTP Session and Cookies in
> > > JAX-RPC client
> > > > > > (JWSDP 1.3)
> > > > > >
> > > > > > So if this is true how can I get cookies (and send them in
> > > > > > subsequent WS access) if those cookies are other than
> > > jsessionid.
> > > > > >
> > > > > >
> > > > > > Kreso
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Kevin Jones [mailto:kevinj_at_develop.com]
> > > > > > > Sent: 06. kolovoz 2004 11:17
> > > > > > > To: users_at_jax-rpc.dev.java.net
> > > > > > > Subject: RE: Accessing HTTP Session and Cookies in
> > > > JAX-RPC client
> > > > > > > (JWSDP
> > > > > > > 1.3)
> > > > > > >
> > > > > > >
> > > > > > > If you are using HttpSession then the cookie sent
> is called
> > > > > > jsessionid
> > > > > > > and this is handled by the stub directly (if you set the
> > > > > > > SESSION_MAINTAIN_PROPERTY property). However for other
> > > > > > cookies you are
> > > > > > > on your own. I'm not sure there's anyway to get
> at the HTTP
> > > > > > connection
> > > > > > > from the generated stubs, unless Bobby or one of the other
> > > > > > folks knows
> > > > > > > differently?
> > > > > > >
> > > > > > > Kevin Jones
> > > > > > > http://kevinj.develop.com
> > > > > > >
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: Merten Schumann [mailto:Merten.Schumann_at_asg.com]
> > > > > > > > Sent: 05 August 2004 07:22
> > > > > > > > To: users_at_jax-rpc.dev.java.net
> > > > > > > > Subject: RE: Accessing HTTP Session and Cookies in
> > > > > JAX-RPC client
> > > > > > > > (JWSDP 1.3)
> > > > > > > >
> > > > > > > > Hm, shouldn't the cookies get handled automatically
> > > > > when you use
> > > > > > > > HTTP Sessions?
> > > > > > > >
> > > > > > > > How do you set the cookie on the WS server side? You
> > > > > have to call
> > > > > > > > <ServletEndpointContext> .getHTTPSession() to use HTTP
> > > > > > Sessions at
> > > > > > > > all ...
> > > > > > > > Merten
> > > > > > > >
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: Kresimir Kers (ZG/ETK)
> > > > > [mailto:kresimir.kers_at_ericsson.com]
> > > > > > > > > Sent: Wednesday, August 04, 2004 10:06 AM
> > > > > > > > > To: 'users_at_jax-rpc.dev.java.net'
> > > > > > > > > Subject: Accessing HTTP Session and Cookies in JAX-RPC
> > > > > > > > client (JWSDP
> > > > > > > > > 1.3)
> > > > > > > > >
> > > > > > > > > Hello,
> > > > > > > > >
> > > > > > > > > is it possible to get Cookie from response in JAX-RPC
> > > > > > > > client and how
> > > > > > > > > to do it.
> > > > > > > > > I have situation where WS Server set some
> cookie in HTTP
> > > > > > > > response that
> > > > > > > > > caries WS response that I need to obtain in client and
> > > > > > store for
> > > > > > > > > subsequent calls to WS. Setting of
> > > > > > > > SESSION_MAINTAIN_PROPERTY in Stub
> > > > > > > > > class does not solve my issue. Of course I
> also need to
> > > > > > set that
> > > > > > > > > stored cookie to the HTTP call in next call to WS.
> > > > > > > > >
> > > > > > > > > Thanx,
> > > > > > > > >
> > > > > > > > > Kreso
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> ---------------------------------------------------------------------
> > > > > > > > > To unsubscribe, e-mail:
> > > > users-unsubscribe_at_jax-rpc.dev.java.net
> > > > > > > > > For additional commands, e-mail:
> > > > > users-help_at_jax-rpc.dev.java.net
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> ---------------------------------------------------------------------
> > > > > > > > To unsubscribe, e-mail:
> > > users-unsubscribe_at_jax-rpc.dev.java.net
> > > > > > > > For additional commands, e-mail:
> > > > users-help_at_jax-rpc.dev.java.net
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> ---------------------------------------------------------------------
> > > > > > > To unsubscribe, e-mail:
> > users-unsubscribe_at_jax-rpc.dev.java.net
> > > > > > > For additional commands, e-mail:
> > > users-help_at_jax-rpc.dev.java.net
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail:
> users-unsubscribe_at_jax-rpc.dev.java.net
> > > > > > For additional commands, e-mail:
> > users-help_at_jax-rpc.dev.java.net
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > >
> >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: users-unsubscribe_at_jax-rpc.dev.java.net
> > > > > For additional commands, e-mail:
> users-help_at_jax-rpc.dev.java.net
> > > > >
> > > >
> > > >
> > >
> >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: users-unsubscribe_at_jax-rpc.dev.java.net
> > > > For additional commands, e-mail: users-help_at_jax-rpc.dev.java.net
> > > >
> > > >
> > >
> > >
> > >
> >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe_at_jax-rpc.dev.java.net
> > > For additional commands, e-mail: users-help_at_jax-rpc.dev.java.net
> > >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe_at_jax-rpc.dev.java.net
> > For additional commands, e-mail: users-help_at_jax-rpc.dev.java.net
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jax-rpc.dev.java.net
> For additional commands, e-mail: users-help_at_jax-rpc.dev.java.net
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_jax-rpc.dev.java.net
For additional commands, e-mail: users-help_at_jax-rpc.dev.java.net