Yeah, something like that would be really useful for modules like ours.
Dk.
> On Dec 18, 2019, at 6:44 AM, Alan Carroll
> 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 mi
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:
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
> wrote:
>
> I don't see any direct way to do that - the optiona
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 b
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 rel
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 litera
as it is part of the specification and not
> considered part of the name or value of the field.
>
> On Mon, Dec 9, 2019 at 5:36 PM Dk Jack wrote:
>
> > Does TS maintain two copies of the header values? Because the origin
> > is receiving the unmodified header values i.e.
new field the space
is added automatically as it is part of the specification and not
considered part of the name or value of the field.
On Mon, Dec 9, 2019 at 5:36 PM Dk Jack wrote:
> Does TS maintain two copies of the header values? Because the origin
> is receiving the unmodified head
Does TS maintain two copies of the header values? Because the origin
is receiving the unmodified header values i.e. with spaces...
On Mon, Dec 9, 2019 at 3:15 PM Valentín Gutierrez
wrote:
>
> IIRC TS normalizes header names and values to avoid inconsistencies and
> potential securi
:testhost1
> > 20191209.22h18m52s [INFO] User-Agent:curl/7.47.0
> > 20191209.22h18m52s [INFO] Content-Type:woof
> > 20191209.22h18m52s [INFO] Accept-Encoding:gzip,deflate
> > 20191209.22h18m52s [INFO] Accept-Language:en-ca
> > 20191209.22h18m52s [INFO] Accept:applicat
ser-Agent:curl/7.47.0
> 20191209.22h18m52s [INFO] Content-Type:woof
> 20191209.22h18m52s [INFO] Accept-Encoding:gzip,deflate
> 20191209.22h18m52s [INFO] Accept-Language:en-ca
> 20191209.22h18m52s [INFO] Accept:application/json,text/plain,*/*
>
> ---
-----
Notice the spaces are stripped off from all header values. I observed
that the server (origin) receives headers with the spaces being
stripped. Is this behavior specific to atscppapi? Is there a way to
prevent this from happening?
When I captured tcpdump, the incoming request has the spaces. Any help
is appreciated. Thanks.
Dk.
12 matches
Mail list logo
