[Twisted-Python] Final request URI from an Agent response
Hello Twisters, I'm interested in working on ticket #5435: The ability to discover the final URI of an Agent request/response. Thomas summarised a previous IRC conversation on this topic quite well in a comment on the ticket [1]. The biggest issue I've encountered so far is that Request.uri is a relative URI. Since it is not possible to reconstruct an absolute URI given the information that Request has, at the very least the URI scheme is lost, we have a few options: * Allow Request.uri to be either an absolute URI or a relative URI byte string, however this means that consumers of this attribute need to be aware that it could be either; * Add a new attribute/method to Request (and parameter to Request.__init__) for the absolute URI, again this means that consumers need to be aware that the absolute URI might not be present. If we are to change Request's URI API, it would be a good idea to do this as few times as possible. (One seems like a good number to me.) JP commented that it would be nice if there was an object that represented a URL we could use, referring to ticket #5388. And although I would love to see #5388 finished (and might even be persuaded to work on it), discussions with Itamar and reading ticket comments have left me weary of the many nuanced complexities of this task. What are the thoughts on changing the meaning of Request.uri? Should the IRI branch be finished before attempting this ticket? (Note that this doesn't necessarily include my volunteering.) [1] <https://twistedmatrix.com/trac/ticket/5435#comment:9> -- Jonathan
On Fri, Mar 15, 2013 at 4:11 AM, Jonathan Jacobs < jonathan+twisted@jsphere.com> wrote:
Should the IRI branch be finished before attempting this ticket? (Note that this doesn't necessarily include my volunteering.)
The IRI ticket should *not* be a dependency. It would be nice, but it's unlikely it will happen anytime soon.
On 02:20 am, itamar@futurefoundries.com wrote:
On Fri, Mar 15, 2013 at 4:11 AM, Jonathan Jacobs < jonathan+twisted@jsphere.com> wrote:
Should the IRI branch be finished before attempting this ticket? (Note that this doesn't necessarily include my volunteering.)
The IRI ticket should *not* be a dependency. It would be nice, but it's unlikely it will happen anytime soon.
The hard part of the IRI ticket is parsing all the extremely complex forms in which an IRI can appear, right? If so, I agree. However, there's no reason we can't have an object that represents an IRI *without* writing a parser for all those forms. Agent only needs minimal functionality of being able to figure out the hostname, port number, and whatever makes up the rest. Jean-Paul
On Sat, Mar 16, 2013 at 3:49 PM, <exarkun@twistedmatrix.com> wrote:
However, there's no reason we can't have an object that represents an IRI *without* writing a parser for all those forms. Agent only needs minimal functionality of being able to figure out the hostname, port number, and whatever makes up the rest.
Isn't this currently called twisted.web.client._URL? (Although _URL still needs some more data to fill this role.) I do like this idea, although I keep coming back to wondering how we provide this to Request initially, an additional parameter was not received with much enthusiasm on IRC. It would be unfortunate if Request.uri is going to mean "the relative URI" forever. And, when the IRI ticket is finally complete, are we going to have to introduce yet another API for getting an IRI object?
On Sat, Mar 16, 2013 at 7:52 AM, Jonathan Jacobs < jonathan+twisted@jsphere.com> wrote:
On Sat, Mar 16, 2013 at 3:49 PM, <exarkun@twistedmatrix.com> wrote:
However, there's no reason we can't have an object that represents an IRI *without* writing a parser for all those forms. Agent only needs minimal functionality of being able to figure out the hostname, port number, and whatever makes up the rest.
Isn't this currently called twisted.web.client._URL? (Although _URL still needs some more data to fill this role.)
I do like this idea, although I keep coming back to wondering how we provide this to Request initially, an additional parameter was not received with much enthusiasm on IRC. It would be unfortunate if Request.uri is going to mean "the relative URI" forever.
An additional attribute is not ideal... but it's better than changing an existing attribute's contents, which is *really* backwards incompatible. It's probably too late for the ideal solution anyway, let's just get a decent one done.
And, when the IRI ticket is finally complete, are we going to have to introduce yet another API for getting an IRI object?
Or just IRI.fromString() or something. Why don't you start coding, and we can then talk about actual implementation details? It's going to be pretty short, so any review comments should hopefully not take too long to address. -Itamar
On 02:52 pm, jonathan+twisted@jsphere.com wrote:
On Sat, Mar 16, 2013 at 3:49 PM, <exarkun@twistedmatrix.com> wrote:
However, there's no reason we can't have an object that represents an IRI *without* writing a parser for all those forms. Agent only needs minimal functionality of being able to figure out the hostname, port number, and whatever makes up the rest.
Isn't this currently called twisted.web.client._URL? (Although _URL still needs some more data to fill this role.)
Something like it, yea. Although please do not expose a tuple subclass publicly (in fact, if you could get rid of that tuple subclass while working on this, I don't think it would hurt. :)
I do like this idea, although I keep coming back to wondering how we provide this to Request initially, an additional parameter was not received with much enthusiasm on IRC. It would be unfortunate if Request.uri is going to mean "the relative URI" forever.
Yes. I wish the API had been more well considered before being exposed publicly.
And, when the IRI ticket is finally complete, are we going to have to introduce yet another API for getting an IRI object?
The object we expose now should be forward compatible with the future perfect IRI object so that we can replace it with the IRI object when that is ready. Jean-Paul
On Mar 16, 2013, at 7:52 AM, Jonathan Jacobs <jonathan+twisted@jsphere.com> wrote:
And, when the IRI ticket is finally complete, are we going to have to introduce yet another API for getting an IRI object?
It seems to me that it would be a compatible change to have an IRI.fromString method that could do some extremely straightforward parsing - heck, even ASCII-only! - and then add support for more complex forms later. After all, we have APIs like clientFromString which explicitly support extension; the contract is just (string)->something or (string)->CantGiveYouSomething; the exact format of the string is up to modification. (Although I would suggest that once we have tests for parsing a particular form we should never _remove_ that form...) -glyph
participants (4)
-
exarkun＠twistedmatrix.com -
Glyph -
Itamar Turner-Trauring -
Jonathan Jacobs