Presently, non-standard ports are not included when building request string out. Some filters allow to specify, for example, resources loaded over host:PORT_NUMBER, binding that rule to a request served over a certain port. Since port numbers are required to be declared in HTTP headers whenever the request comes over any non-standard port, this should be checked and built into requests. Whether or not two request strings (that are passed to filters) should be built (one with the port, one without) is something to be pondered.
All of this doesn't matter, however, until filtering on ports other than 80 and 443 is possible. This will require a form of port-independent protocol mapping as well as flow tracking. Packets indicating a new connection have to have the payload inspected to determine if its TLS or plain HTTP, then the flow needs to be tracked till completion. This will enable all HTTP traffic to be captured regardless of the port used, and also filtered.
Presently, non-standard ports are not included when building request string out. Some filters allow to specify, for example, resources loaded over
host:PORT_NUMBER
, binding that rule to a request served over a certain port. Since port numbers are required to be declared in HTTP headers whenever the request comes over any non-standard port, this should be checked and built into requests. Whether or not two request strings (that are passed to filters) should be built (one with the port, one without) is something to be pondered.All of this doesn't matter, however, until filtering on ports other than
80
and443
is possible. This will require a form of port-independent protocol mapping as well as flow tracking. Packets indicating a new connection have to have the payload inspected to determine if its TLS or plain HTTP, then the flow needs to be tracked till completion. This will enable all HTTP traffic to be captured regardless of the port used, and also filtered.