1 | initial version |
A capture filter you can use is http.request.full_uri contains "google.com/blah" || http.request_for.uri contains "google.com/blah"
. Note that this will only capture the HTTP traffic like GETs and their responses, not the actual data, which will be the majority of the packets. Also note that this should cover cases like "google.com/blah/foo.html" as we're using the contains
qualifier
The root of the problem is that Wireshark will differentiate source/dest IP and name based on different subdomains/IP addresses. google.com/blah and google.com/bloop both point to the same server. More info can be found on this Stackoverflow question. If somehow there is a different server involved (let's say google.com/drive redirects to drive.google.com), then you can filter by destination IP address.
2 | No.2 Revision |
A capture display filter you can use is http.request.full_uri contains "google.com/blah" || http.request_for.uri contains "google.com/blah"
. Note that this will only capture the HTTP traffic like GETs and their responses, not the actual data, which will be the majority of the packets. Also note that this should cover cases like "google.com/blah/foo.html" as we're using the contains
qualifier
The root of the problem is that Wireshark will differentiate source/dest IP and name based on different subdomains/IP addresses. google.com/blah and google.com/bloop both point to the same server. More info can be found on this Stackoverflow question. If somehow there is a different server involved (let's say google.com/drive redirects to drive.google.com), then you can filter by destination IP address.
3 | No.3 Revision |
A display filter Capture filters will not be able to do this unless you can use is specify a different IP address for the http.request.full_uri contains "google.com/blah" || http.request_for.uri contains "google.com/blah"
. Note that this will only capture HTTP traffic like GETs and their responses, not the actual data, which will be the majority of the packets. Also note that this should cover cases like "google.com/blah/foo.html" as we're using the contains
qualifier
server. The root of the problem is that Wireshark will differentiate source/dest IP and name based on different subdomains/IP addresses. google.com/blah and google.com/bloop both point to the same server. More info can be found on this Stackoverflow question. If somehow there is a different server involved (let's say google.com/drive redirects to drive.google.com), then you can use a display filter by destination IP address.
4 | No.4 Revision |
Capture filters will not be able to do this unless you can specify a different IP address for the server. The root of the problem is that Wireshark will differentiate source/dest IP and name based on different subdomains/IP addresses. google.com/blah and google.com/bloop both point to the same server. More info can be found on this Stackoverflow question. If somehow there is a different server involved (let's say google.com/drive redirects to drive.google.com), then you can use a display filter by destination IP address.
Edited: To limit the scope to capture filters
5 | No.5 Revision |
Capture filters will not be able to do this unless you can specify a different IP address for the server. The root of the problem is that Wireshark will capture filters use a more limited syntax. Capture filters can differentiate source/dest IP and name based on different subdomains/IP addresses. google.com/blah and google.com/bloop google.com/bloop; however, both point to the same server. More info can be found on this Stackoverflow question. If somehow there is a different server involved (let's say google.com/drive redirects to drive.google.com), then you can use a display capture filter by destination IP address.like dst drive.google.com
.
Edited: To limit the scope to capture filters