Re: Fwd: Re: HTTP and EARL

Shadi Abou-Zahra wrote:

>> I'm excluding that case, because it seems to me the whole discussion
>> is too far from dealing with the case of *applications*.  To deal
>> meaningfully with POST, we have to be evaluating the entire application,
>> not just a results page in isolation.  And we're a very long way
>> from describing that.
> 
> 
> A simple example: An HTML form is submitted using POST and returns
> content according to the specific form field values. It seems to me
> useful to record all the parameters sent to the server in order to
> regenerate receive the same content from the server. Would something
> like the structure below work for our usage?
> 
> <earl:request about="{protocol}://{server}[/location][?parameters]">
>  <earl:request-parameter about="{value-pair}"\>
>  ....
> </earl:request>

Yes, that's an option.

But when you write <earl:request about="url"> ..., you still need to
record date and headers as discussed in my note.

But this formulation has a few problems.  It's effectively limited to
POSTS of type application/x-www-form-urlencoded, in that it doesn't
really make sense to include file uploads this way, and any other
(nonstandard) type would have to be dealt with ad-hoc.  And for that
type, it's exactly equivalent to a GET Query string, so we can
reasonably record the two in the same way too.

More fundamentally, a HTML form with POST is a very limited thing to
look at.  I think it's  more productive to look at the application as
a whole: even in the simplest cases, presenting a form, filling and
submitting it, and obtaining results is not the same as merely
evaluating HTML pages.  That's why I think bringing it in to a
discussion of how we record a single HTTP transaction is of limited
value, and it's not clear that it's worth the additional complexity.

Record Method as a property of Request by all means.  But further
complexity belongs in another discussion, IMO.

-- 
Nick Kew

Received on Thursday, 19 May 2005 14:12:21 UTC