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