Opened 14 years ago
Closed 13 years ago
Last modified 13 years ago
#8132 closed defect (fixed)
CDS_Control/Browse can't process IDs containing '&' in GET requests
Reported by: | Owned by: | beirdo | |
---|---|---|---|
Priority: | minor | Milestone: | 0.25 |
Component: | MythTV - UPnP | Version: | unknown |
Severity: | medium | Keywords: | |
Cc: | Ticket locked: | no |
Description
The problem is in HTTPRequest::GetParameters? - it performs substitutions on %26 and & BEFORE splitting the get request into fields. So no matter how you escape the ampersands in a program name, it always gets interpreted as a field separator.
For example, "ObjectID=RecTv?/1/key=Law%20%26%%20Order" would first get unescaped to "ObjectID=RecTv?/1/key=Law & Order", and then split up into an "ObjectID" field with a value of "RecTv?/1/key=Law " and an "Order" field.
Of course, standard UPnP would be making SOAP requests rather than GET requests, but having GET working properly is handy for testing.
Change History (8)
comment:1 Changed 14 years ago by
Owner: | changed from dblain to beirdo |
---|---|
Status: | new → assigned |
comment:2 Changed 14 years ago by
Status: | assigned → accepted |
---|
comment:3 Changed 14 years ago by
Milestone: | unknown → 0.25 |
---|---|
Status: | accepted → infoneeded |
What is the necessity of this? As mentioned, UPnP is meant to use SOAP. This shouldn't be necessary. Please let me know what the use case is.
comment:4 Changed 14 years ago by
One general use case is for debugging. My specific use case is an attempt to make a myth client for Yahoo! widgets, which would run natively on TVs that support them. The only real option for client requests in that API is HTTP GET requests.
Since the API supports GET requests, and it's only a matter of reshuffling two lines of code so that escaping happens after the GET is broken into separate fields, instead of before, I don't see the harm.
comment:6 Changed 13 years ago by
Status: | infoneeded → assigned |
---|
comment:7 Changed 13 years ago by
Resolution: | → Fixed |
---|---|
Status: | assigned → closed |
Fixed in f76028ba358 on master.
comment:8 Changed 13 years ago by
Resolution: | Fixed → fixed |
---|
Fix passing a URL key/value containing %26 (escaped &)
It seems that this code *only* deals with Parameters in the URL (maybe on POST too), but not in SOAP requests from UPnP clients. It should be a benign change to not mess with %26 in the params string before splitting on &. Any self-respecting client will know that & separates the keys, and not to escape them. If this breaks any specific clients, we will have to put in a workaround for the broken client perhaps.
Fixes #8132.
Changeset: f76028ba35811818f75c3d39faa4479b024bc846
I will attempt to look into this once I have recorded a file with an & in it (Rizzoli & Isles -- tomorrow).