Re: p:http-request Review

/ Alex Milowski <> was heard to say:
| Here are the issues I have from the last time we looked at p:http-request
|   - header conflicts [1]

I think this is editorial. I don't think I care strongly about the
rules, I just need to be able to understand them. My inclination is to
say that the headers I specifically request should be used. If they
make no sense, they should be ignored. But if you prefer to make them
an error if they make no sense, I won't fuss.

|   - invalid method creates a dynamic error

I think this is straightforward, though I'd like to change my wording :-)

If the method isn't understood by the processor (method="FRIBBLE")
that should be a dynamic error. (Perhaps we should say that processors
must support GET and POST, but I don't feel strongly. I don't want to
enumerate an exclusive list of methods.)

If the attempt to access the specified URI fails, that should be a
dynamic error. Nevermind what I said about "not an http URI".

|   - href uri isn't a HTTP-based protocol (allows for https) [2]

Oh, let's not fuss about this. The 90% case is surely an http request.
The https protocol *is* http, it just has a different scheme name to
avoid a round-trip. (The alternative design would have been to use
http: but have the unsecure request rejected, but that would make all
secure connections require two round trips, so they went with a
different scheme name.)

If the http-request object accepts file: protocol URIs, so be it.

If someone has a really clever alternative name, fine, but I'd like
not to spend telcon time on this one if we can avoid it.

|   - multiple bodies is now handled by multipart [3]

Makes sense to me.

|   - making it required [4]

I'm in favor.

Does anyone think any of these issues need further discussion?

| [1]

| [2]
| [3]
| [4]

                                        Be seeing you,

Norman Walsh <> | We are thinking beings, and we cannot            | exclude the intellect from
                              | participating in any of our
                              | functions.--William James

Received on Tuesday, 3 July 2007 12:16:53 UTC