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