You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In case of a compressed name, we'd have to jump to the previously read uncompressed section.
I suppose I could read the header part and questions separately, one by one in a loop, but I'd like to solve it using attributes as that would be more elegant and more concise.
I was thinking about map, or cond & seek_from_start combined (but that's not possible). Can I somehow access the already read uncompressed name?
For example, if we query for abc.longname.com and def.longname.com, and the second name uses compression, we'd have to jump after def to the first longname.com and re-read it or re-use it somehow.
Perhaps it would be nice if we could combine cond with seek* and other attributes.
What would be the best (the most elegant) way to solve this now?
The text was updated successfully, but these errors were encountered:
I believe this could be useful for other formats & protocols as well.
RFC 1035 4 Messages
RFC 1035 4.1.4. Message compression
The highest two bits of the first byte (big-endian), if set, define a pointer. If they are reset, they define the label length.
I've been using the until attribute, to read until the terminating (NULL) character, but that only works for uncompressed names.
I am reading a whole message at once.
In case of a compressed name, we'd have to jump to the previously read uncompressed section.
I suppose I could read the header part and questions separately, one by one in a loop, but I'd like to solve it using attributes as that would be more elegant and more concise.
I was thinking about
map
, orcond
&seek_from_start
combined (but that's not possible). Can I somehow access the already read uncompressed name?For example, if we query for
abc.longname.com
anddef.longname.com
, and the second name uses compression, we'd have to jump afterdef
to the firstlongname.com
and re-read it or re-use it somehow.Perhaps it would be nice if we could combine
cond
withseek*
and other attributes.What would be the best (the most elegant) way to solve this now?
The text was updated successfully, but these errors were encountered: