Summary: | Don't test blocking 255.255.255.255 with no port | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Pam Greene (IRC:pamg) <pam> | ||||||
Component: | Page Loading | Assignee: | Pam Greene (IRC:pamg) <pam> | ||||||
Status: | RESOLVED FIXED | ||||||||
Severity: | Normal | CC: | darin | ||||||
Priority: | P2 | ||||||||
Version: | 528+ (Nightly build) | ||||||||
Hardware: | All | ||||||||
OS: | All | ||||||||
Attachments: |
|
Description
Pam Greene (IRC:pamg)
2008-10-10 13:26:19 PDT
Created attachment 24274 [details]
Fixed test and Mac + Leopard results
Start with port 1 on the initial load rather than no port.
Comment on attachment 24274 [details]
Fixed test and Mac + Leopard results
This doesn't seem right. We do need a test of the case with no specific port. It's a separate code path, and in the past there have been bugs with it. And this regression test will catch us if we break it again.
I assume that people at Google are running into this because of the Google proxy configuration. Or is this a Chrome-specific issue?
What possible solutions are there besides removing the test?
review- for now
Many proxies (such as squid proxies) will send you content with an error message in it rather than reporting a nonexistant domain. Although I think this is stupid, it's pretty common. I don't think it's possible to write a test that depends on the network to return that some address doesn't exist. Could we split the no-port case into its own test file? That way Chromium (and any other ports subject to the same problem) could skip that one part while still keeping deterministic coverage of all the rest. +darin since he might not have seen pam's comment. Created attachment 29204 [details]
split no-port case into separate test
For concrete consideration, here's a patch that splits the test as described above, moving the no-port case to a separate file.
|