webui: url decode POST values; fix seeking

[blaenk]

In the webui, I noticed the seeking wasn't working correctly, it would always seek to 3 minutes and some seconds, regardless of the video.

I took a look at CWebClientSocket::OnCommand in WebClientSocket.cpp which handles the seeking and I noticed it was parsing the position parameter as if it were already url decoded, but in fact it wasn't.

I changed the parsing to take into account the url encoded colons (%3A), it still supports the optional milliseconds parameter. I also did away with the TCHAR c variable which was used as a placeholder to parse the colons.

This is my first contribution, so let me know if there's something I should do differently.

[XhmikosR]

@Underground78: can you review this tonight?

[blaenk]

@XhmikosR Oh yeah, I'm actually matching against the string literal %3A and since it includes a % I need to escape it with another %. Of course, %3A is the url encoded colon, :

[XhmikosR]

Allright, so just update the patch when you can and force push.

[Underground78]

I will have a better look tonight but I think that it might be better to actually URL decode the param and keep the separator "free".

[blaenk]

@Underground78 I agree. I'll look around to see if we have an existing function for that.

[blaenk]

I added url decoding of parameter values in ParsePostData, so the actual seeking parameter parsing is a lot simpler now.

I used AtlUnescapeUrl to url decode and CString::GetBuffer to allocate a buffer for the decoded string.

This is my first time using ATL/MFC so let me know if you think there's a better way.

[Underground78]

Hmm I need to double check if we aren't doing UrlDecode twice in some places with that commit. Also I think the %c should stay as it was.

[blaenk]

Yeah, I found this just now.

It seems like only the GET parameter values are being decoded, but not POST. Should we move url decoding to the block after that? The block where we set each value in m_request?

In the meantime I'll change my commit to use the existing function though (UrlDecode) instead of AtlUnescapeUrl.

[blaenk]

Oh, and do you want me to revert to the %c parsing then? I imagine because it could be the colon is multi-byte? Although if that's the case, shouldn't _T(":") reflect that?

I don't know to be honest, I'll defer to your experience. If you want me to revert to %c I will.

[Underground78]

Yeah I prefer if we keep the %c since it's less restrictive and we don't really care about what the separator is.

[blaenk]

Ah I understand. I'll revert that hunk.

[Underground78]

Merged (243e149), thanks for your contribution.

[blaenk]

Sure, glad I could help.