@Underground78: can you review this tonight?

@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, :

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

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".

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

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.

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.

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.

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.

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

Ah I understand. I'll revert that hunk.

Merged (243e149), thanks for your contribution.

Sure, glad I could help.