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
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?
On Mon, Dec 16, 2019 at 11:54 AM Alan Carroll
wrote:
>
> This behavior is intrinsic to the plugin API. The values returned ar
This behavior is intrinsic to the plugin API. The values returned are the
equivalent of `std::string_view` and directly reference the appropriate
parts of the header. The spaces aren't "stripped" per se, it is simply that
the views don't include the spaces. When constructing a new field the space
i
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 security issues
>
> O
IIRC TS normalizes header names and values to avoid inconsistencies and
potential security issues
On Tue, Dec 10, 2019, 08:08 Walt Karas
wrote:
> It looks like TS is discarding spaces that are unnecessary to the meaning
> of the message.
>
> On Mon, Dec 9, 2019 at 4:54 PM Dk Jack wrote:
>
> > H
It looks like TS is discarding spaces that are unnecessary to the meaning
of the message.
On Mon, Dec 9, 2019 at 4:54 PM Dk Jack wrote:
> Hi,
> I am using the atscppapi and I am noticing something weird. When I
> send a curl request, here's list of headers curl prints.
>
> --
11 matches
Mail list logo
