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? >>>> >>>> >>
