Yeah, something like that would be really useful for modules like ours. Dk.
> On Dec 18, 2019, at 6:44 AM, Alan Carroll > <solidwallofc...@verizonmedia.com.INVALID> wrote: > > I'm trying to think how that could be done. The best option would be to > save aside the original buffer, which is currently discarded after parsing. > That might not be too bad to implement, with a configuration switch to > indicate whether the raw buffer should be preserved. > >> On Tue, Dec 17, 2019 at 7:02 PM Dk Jack <dnj0...@gmail.com> wrote: >> >> Thanks Alan. Would be nice to have in future if possible. We have an nginx >> module as well, where the module can access to original raw string. We’ll >> have live with this for now. >> >> Dk. >> >>> On Dec 17, 2019, at 3:56 PM, Alan Carroll >> <solidwallofc...@verizonmedia.com.INVALID> wrote: >>> >>> I don't see any direct way to do that - the optional white space is >> mostly >>> ignored. The one trace that's left is the relationship between the >> address >>> of the name and value of the field. Even if these are copied in to the >>> HdrHeap, they are copied as a pair. Therefore the amount of whitespace >>> could be computed as (value.data() - (name.data() + name.size())) - 1 >>> (don't count the colon). This won't work for fields where the value has >>> been changed, because the new value will be independent. >>> >>>> On Tue, Dec 17, 2019 at 4:41 PM Dk Jack <dnj0...@gmail.com> wrote: >>>> >>>> Perhaps, I should have started with the use case. Yes, our module is >>>> sensitive to the space in the headers. Our module implements security >>>> policies. One of the things we look at is headers and their values. How >>>> they compare when a normal browser sends them vs when sent using a >> script >>>> Etc. We rely on these sort anomalies to tease out the good from the bad. >>>> Not able extract the exact string that was sent by the client reduces >> our >>>> effectiveness. Hope you now understand the motivation behind my >> question. >>>> Thanks. >>>> >>>> >>>> >>>>> On Dec 17, 2019, at 7:23 AM, Alan Carroll >>>> <solidwallofc...@verizonmedia.com.INVALID> wrote: >>>>> >>>>> You are seeing them "as is" - the view is literally the memory in which >>>>> those values are stored. The space between the colon and the value is >> not >>>>> part of the value, it's part of the syntax no different than the >> colon. >>>>> That is, you >>>>> used "%s:%s" to print the name/value for the field. Note the literal >>>> colon >>>>> - that should be a literal colon, space because that is part of the >>>> syntax. >>>>> See here - https://tools.ietf.org/html/rfc7230#section-3.2 - note the >>>>> "value" part of the definition is distinct from the optional white >> space >>>>> (OWS). >>>>> >>>>> I'm unclear as to what you want to accomplish - if it's printing it >>>> nicer, >>>>> just put a space in your printf format string. Do you have some >>>> application >>>>> that is sensitive to the amount of white space? >>>>> >>>>>> On Mon, Dec 16, 2019 at 6:46 PM Dk Jack <dnj0...@gmail.com> wrote: >>>>>> >>>>>> Thans Alan, >>>>>> >>>>>> I can understand when constructing a new field, but the behavior I saw >>>> was >>>>>> for >>>>>> incoming request headers. Is there an option to see the received >> headers >>>>>> as is? >>>>>> >>>>>> >>>> >>
