[Oisf-devel] libhtp - do not store non key-value param in query

Anoop Saldanha anoopsaldanha at gmail.com
Wed Jun 19 16:07:01 UTC 2013


On Wed, Jun 19, 2013 at 3:11 PM, Ivan Ristic <ivan.ristic at gmail.com> wrote:
> On Tue, Jun 18, 2013 at 2:21 PM, Anoop Saldanha <anoopsaldanha at gmail.com> wrote:
>> On Mon, Jun 17, 2013 at 6:33 PM, Ivan Ristic <ivan.ristic at gmail.com> wrote:
>>> On Mon, Jun 17, 2013 at 9:24 AM, Anoop Saldanha <anoopsaldanha at gmail.com> wrote:
>>>> On Mon, Jun 17, 2013 at 1:52 PM, Anoop Saldanha <anoopsaldanha at gmail.com> wrote:
>>>>> ?name1&name2=value2
>>>>> ?name1=&name2=value2
>>>>>
>>>>> In both these query strings, for param "name1", param->value is
>>>>> non-NULL and len 0.
>>>>>
>>>>> Maybe for the first query string, we should set the param->value
>>>>> as NULL, so that we can differentiate it from the second query where
>>>>> name1 is in the key-value format but without the value set?
>>>
>>> I don't find it natural to use NULL. In both cases the parameter
>>> exists, which -- to me -- means it has to have a value.
>>>
>>> Do you have a use case where the difference matters?
>>>
>>
>> Yes.  In my case I am trying to generate the query string using the
>> individual params, and I'd need to know whether it was in the form of
>> a key-value in the raw query or not, based on which I'd append a "="
>> after the param name.
>
> Why are you reconstructing the query string that way? Why not just
> take the query (as a single string), and perform URL decoding on it?
> Seems to me it amounts to the same thing, only easier to implement.
>

>From the other thread, since it looks like we'll be having a public
version of query decoding API, I won't need this anymore.

>
>>> It's not a change I would want to introduce in 0.5.x, because at the
>>> moment value is guaranteed/expected to not be NULL.
>>>
>>>
>>>> P.S: I have also asked the above question in the mail thread - "libhtp
>>>> 0.5.x integration - bug 775" on oisf-devel.  Please ignore that.
>>>>
>>


-- 
-------------------------------
Anoop Saldanha
http://www.poona.me
-------------------------------



More information about the Oisf-devel mailing list