[fpc-pascal] Using fphttpclient to simulate web action sequence

Michael Van Canneyt michael at freepascal.org
Thu Apr 30 21:00:33 CEST 2015



On Thu, 30 Apr 2015, leledumbo wrote:

>> Just extract the and save the value of the Set-Cookie header ?
>> I always store the cookies explicitly.
>
> If that's so, the current Cookies property implementation seems broken. I
> try to debug and indeed I found that each Set-Cookie line overrides the
> previous if there are more than one Set-Cookie (procedure DoCookies,
> FCookies gets cleared at the start).

I will check this.

>
> I try to log Cookies.Text, and for instance:
>
> Set-Cookie: cart_code=f654373c175ac6e86da22c7400a146f0; expires=Fri,
> 29-Apr-2016 16:40:05 GMT; path=/
>
> results in:
> cart_code=f654373c175ac6e86da22c7400a146f0
> expires=Fri, 29-Apr-2016 16:40:05 GMT
> path=/

I will check this. Sounds like something in the cookie parsing is wrong.

>
> which is not right since expires and path are cookie attributes instead of
> cookie value (I even wonder if TStrings is the right choice to store
> cookies). Guess I'll have to use Free + re-Create + search and parse
> Set-Cookie manually then.
>
>> We can think of a "TCookieJar" class implementation as an option
>
> I guess so, but it's better integrated in fphttpclient so it can act as a
> true browser session instead of just a one time request caller.

That I will definitely not do. I prefer the component to be stateless as much as possible.
Which is why I would separate out the hypothetical TCookieJar.

If you want that you'll need to make a separate class which combines the two into one class.
It you can then also handle saving cookies for later retrieval, which will be 
pretty much application specific anyway.

>
>> It must
>
> It actually does, but actually one can't prove that by inspecting
> RequestHeaders.Text BEFORE doing http method, because Cookies gets merged
> there DURING the http method.
>
>> I have plans to handle this in TFPHTTPClient
>
> I didn't ask if 302 is a problem, it's a statement that 302 is expected and
> is OK. Does what you say indicates that probably the cause of the stuck
> error?

I meant that I want to have automated handling of 302 (based on a property to enable/disable this, obviously); 
i.e. resubmit the request at the 302 location.

Michael.


More information about the fpc-pascal mailing list