Rewrite Icon fetching#3023
Conversation
Ephemeral Environment
InstructionsDetailsCreating a new environment
Updating an environment
Deletion of an environmentNOTE: Environments will be automatically deleted on merge/close of a PR.
Additional information can be found here. |
ef80a5f to
817c3d9
Compare
justindbaur
left a comment
There was a problem hiding this comment.
Thoughts on passing through the CancellationToken from HttpContext.RequestAborted to all the async calls, this way if the connection gets closed we can stop doing all this work.
With something that has no database side effects I'd normally really want to do that but I can also see an argument against it because we can let the request continue and let it make it into our cache so that we can return the cached version the next time.
withinfocus
left a comment
There was a problem hiding this comment.
Great suggestions from Justin. I see a couple ⛏️ s beyond that but will skip calling them out until this settles.
| _httpClientFactory = httpClientFactory; | ||
| } | ||
|
|
||
| public async Task<IEnumerable<Icon>> RetrieveIconsAsync(Uri requestUri, string domain) |
There was a problem hiding this comment.
💭 Does it make sense to just have this return one? Is there a use case I'm not seeing for providing all of what's found?
There was a problem hiding this comment.
hmm this is pretty interesting. We used to prioritize icon display after pulling, but now that prioritization occurs prior to navigating to a link. That does mean that we could pull only the highest priority and cut down on network requests.
However, if the first link fails, we'd have to go on down the line iteratively. Currently, we just fire off all 10 requests simultaneously and wait for them all to get back to us. Effectively we're discussing changing this from an eager load to a lazy one.
I don't have the data to say which would be better, presumably most links work, but those that don't would suffer in load times.
|
No New Or Fixed Issues Found |
Presents better, fluent handling of message matching and response building.
…e-validated-ip-in-icon-retrieval
|
Looking in to test failures. I swear they weren't happening locally a half hour ago... 😵 |
Content was being disposed when HttResponseMessage was being disposed. This avoids losing our reference to our content and allows multiple usages of the same `MockedHttpMessageResponse`
Extension is shared by testing and allows access to services from our service tests
withinfocus
left a comment
There was a problem hiding this comment.
Ton of changes here, but I think it's making sense to me and has a lot of test coverage. Few questions.
| public class IconFetchingServiceTests : ServiceTestBase<IconFetchingService> | ||
| { | ||
| [Theory] | ||
| [InlineData("www.twitter.com")] // https site |
There was a problem hiding this comment.
❓ Anything special with how this test was handled? Seems the same as the line below.
There was a problem hiding this comment.
From when I stepped through the retrieval it's the same as google, we have just been getting reports that twitter in particular is having problems.
Because this work is so pervasive I have no clue if this test passing represents a functionality change or not, but I wanted this as a canary. If it proves to be flaky on twitter's end I want to remove.
…e-validated-ip-in-icon-retrieval
| private const string _jpegMediaType = "image/jpeg"; | ||
| private static readonly byte[] _jpegHeader = new byte[] { 255, 216, 255 }; | ||
|
|
||
| private const string _svgXmlMediaType = "image/svg+xml"; |
There was a problem hiding this comment.
💭 Does there need to be a code expansion below to check the header? I see this done for the other types.
There was a problem hiding this comment.
I don't think we need to, those are only for formats that we try to infer if we don't get a Media-Type header back or we don't support the media type we got back. I also don't think there are generally "marker" bytes for svg.
There was a problem hiding this comment.
Throwing in an additional test theory with a site that uses an SVG icon would be a nice and quick addition.
There was a problem hiding this comment.
there doesn't need to be mime type detection on the file level. That's just a fallback if the mimetype doesn't exist.
I don't believe svg+xml has a mime type file header (I couldn't find one) so it's not added.
* Rewrite Icon fetching * Move validation to IconUri, Uri, or UriBuilder * `dotnet format` 🤖 * PR suggestions * Add not null compiler hint * Add twitter to test case * Move Uri manipulation to UriService * Implement MockedHttpClient Presents better, fluent handling of message matching and response building. * Add redirect handling tests * Add testing to models * More aggressively dispose content in icon link * Format 🤖 * Update icon lockfile * Convert to cloned stream for HttpResponseBuilder Content was being disposed when HttResponseMessage was being disposed. This avoids losing our reference to our content and allows multiple usages of the same `MockedHttpMessageResponse` * Move services to extension Extension is shared by testing and allows access to services from our service tests * Remove unused `using` * Prefer awaiting asyncs for better exception handling * `dotnet format` 🤖 * Await async * Update tests to use test TLD and ip ranges * Remove unused interfaces * Make assignments static when possible * Prefer invariant comparer to downcasing * Prefer injecting interface services to implementations * Prefer comparer set in HashSet initialization * Allow SVG icons * Filter out icons with unknown formats * Seek to beginning of MemoryStream after writing it * More appropriate to not return icon if it's invalid * Add svg icon test (cherry picked from commit 4377c7a)

Type of change
Objective
Rewrites icon fetching to be more object oriented.
Code changes
HttpClientFactorywith the same settings as the old staticHttpClient/favicon.icoas the resolved icon location.Before you submit
dotnet format --verify-no-changes) (required)