|
midrange.com
Well, that's the tricky part.
If you get a 302 Redirect after posting the form, then you
have to program for that. In other words..
1. Make the request (POST).
2. Read the response. If there's a redirect, you'll need
to make another request to that redirect. Keep doing this
until no more redirects and you get what you want.
This could be done many ways... Redirect I believe is from
the HTTP server config itself. There's also the Location
header, and there's also Meta tags that can change the
location, and possibly JavaScript.
Sounds like the app you're working with may be "hacked"
together a little bit. When I write web apps, I do tend to
use the Location header to redirect after reading a form
from time to time, but never 3 or 4 in a row. :)
I hope this helps get you a little further. I do this for
a living and even I learn something new every time
(supporting my GETURI utility as well as consulting for
this type of work)... But it's basically understanding
HTTP and how a clients talk to servers, etc... It all
makes sense after a while.
And Merry Christmas! :) I accept t-shirts and beer as
well as credit cards LOL!.
And if interested, my GETURI utility may be of help as well
as it wraps the APIs you're using and makes it a little
easier.
Now, just wait until you have a BP that wants to do Client
Authentication with SSL.. Been through that.. what a
headache! :) BTW, it will require PTFs... not sure about
V5R3.. hopefully it's fixed there. Apparently since I had
the first HTTP client using that, IBM hadn't really tested
it and we found some bugs for them.. LOL!
Brad
www.bvstools.com
On Fri, 30 Jul 2004 14:22:05 -0500
daparnin@xxxxxxxxxxxxxxxxxx wrote:
>
>
>
>
> Brad,
>
> Wow. You've come to my rescue twice in one week. I
> might just have to put
> you on my Christmas card list this year. <g> If you
> haven't guessed I'm
> new to this stuff (but learning fast). I wouldn't have
> guessed it but
> passing the cookie info back and forth does make sense as
> a method of
> "logging in".
>
> So, in my situation where it redirects from A to B to C
> back to A then I
> should probably look for the cookie in the header when
> going from A to B
> then pass it back when posting to B and hope that I get
> redirected to D
> instead of C, correct? I'll have to keep an eye on what
> the values are
> when I debug it a few times.
>
> I'll give it a shot and see what happens. Thanks!
>
> Dave Parnin
> Nishikawa Standard Company
> Topeka, IN 46571
> daparnin@xxxxxxxxxxxxxxxxxx
>
>
>
>
>
>
> Brad Stone
>
>
> <brad@xxxxxxxxxxx To:
> Web Enabling the AS400 / iSeries
>
> m>
> <web400@xxxxxxxxxxxx>@SMTP@CTB
>
> Sent by: cc:
> (bcc: David A Parnin/Topeka/NISCO/SPCO)
>
> web400-bounces@mi Subject:
> Re: [WEB400] 302 Redirection Headaches
> drange.com
>
>
>
>
>
>
> 07/30/2004 01:39
>
>
> PM
>
>
> Please respond to
>
>
> Web Enabling the
>
>
> AS400 / iSeries
>
>
> <web400@midrange.
>
>
> com>
>
>
>
>
>
>
>
>
>
> They're most likely using frames... so what you need to
> do
> is view the source for the page with the input fields on
> it, and do a POST to the path specified in the form on
> the
> action tag sending along the appropriate data fields
> (hidden or not). I doubt you'd use the API or any other
> tool to go to a root domain.
>
> After "logging in" many times you will be returned either
> a
> cookie or a session ID. That needs to be saved and sent
> in
> the header of any subsequent request so it thinks you're
> still "logged on". Sometimes apps can be picky as to how
> te headers with cookie/session data are returned, so it
> will take some time.
>
> I've helped many customers in similar scenarios do this
> exact same thing with my GETURI application. Some use
> cookies, some use session IDs. Either have to be parsed
> from the returned header for later use in following
> requests.
>
> Bradley V. Stone
> www.bvstools.com
>
>
> Brad
>
> On Fri, 30 Jul 2004 12:45:49 -0500
> daparnin@xxxxxxxxxxxxxxxxxx wrote:
> >
> >
> >
> >
> > Good morning,
> >
> > I'm trying to adapt Scott Klement's HTTPAPI code to
> send
> > a file to our
> > bank. The digital certificate hurdle has been jumped
> but
> > now I'm facing a
> > seemingly endless 302 redirect problem. Ultimately I
> > want to use Scott's
> > http_url_post() routine to fill in a box with a file
> name
> > but have been
> > playing with the http_url_get() to try to resolve the
> > redirection problem
> > so I can get to that point.
> >
> > The scenario goes like this:
> > When I connect to http://www.bank.com/ it returns a 302
> > redirecting me to
> > http://www.bank.com/a. When I connect to
> > http://www.bank.com/a it returns
> > a 302 redirecting me to http://www.bank.com/b. When I
> > connect to that it
> > gives me a 302 that sends me back to
> > http://www.bank.com/. Argh!!!! How
> > do I debug this? I've looked at the files in /tmp but
> > nothing has jumped
> > out at me.
> >
> > >From a browser perspective I connect to
> > http://www.bank.com, click the
> > login/logout button, and am taken to the page that I
> want
> > to get to however
> > the address in the browser's address box doesn't
> change.
> > How can I tell
> > where my browser is pointed other than the address bar
> > and viewing the
> > source of the initial page? Any thoughts?
> >
> > Dave Parnin
> > Nishikawa Standard Company
> > Topeka, IN 46571
> > daparnin@xxxxxxxxxxxxxxxxxx
> >
> >
> > HTML Source for first page:
> >
> > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
> > <HTML>
> > <HEAD>
> > <TITLE>Logged In</TITLE>
> > </HEAD>
> > <BODY>
> > <CENTER><A HREF="/"
> > onMouseOver="window.status='Continue';return true"><IMG
> > SRC="/icons/stlogo.gif" BORDER=0
> > ALT="Continue"></A></CENTER>
> > <BR>
> > <HTML><P>
> > WARNING! You have accessed a private computer
> system...
> > blah, blah,
> > blah...
> > </P></HTML>
> > <BR>
> > </BODY>
> > </HTML>
> >
> >
> >
> >
> > _______________________________________________
> > This is the Web Enabling the AS400 / iSeries (WEB400)
> > mailing list
> > To post a message email: WEB400@xxxxxxxxxxxx
> > To subscribe, unsubscribe, or change list options,
> > visit:
> http://lists.midrange.com/mailman/listinfo/web400
> > or email: WEB400-request@xxxxxxxxxxxx
> > Before posting, please take a moment to review the
> > archives
> > at http://archive.midrange.com/web400.
> >
>
> Bradley V. Stone
> BVS.Tools
> www.bvstools.com
> _______________________________________________
> This is the Web Enabling the AS400 / iSeries (WEB400)
> mailing list
> To post a message email: WEB400@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/web400
> or email: WEB400-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the
> archives
> at http://archive.midrange.com/web400.
>
>
> _______________________________________________
> This is the Web Enabling the AS400 / iSeries (WEB400)
> mailing list
> To post a message email: WEB400@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/web400
> or email: WEB400-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the
> archives
> at http://archive.midrange.com/web400.
>
Bradley V. Stone
BVS.Tools
www.bvstools.com
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
