Skip to content

Conversation

@anik120
Copy link
Contributor

@anik120 anik120 commented Feb 6, 2025

Description

Reviewer Checklist

  • API Go Documentation
  • Tests: Unit Tests (and E2E Tests, if appropriate)
  • Comprehensive Commit Messages
  • Links to related GitHub Issue(s)

@anik120 anik120 requested a review from a team as a code owner February 6, 2025 16:08
@netlify
Copy link

netlify bot commented Feb 6, 2025

Deploy Preview for olmv1 ready!

Name Link
🔨 Latest commit 09a0392
🔍 Latest deploy log https://app.netlify.com/sites/olmv1/deploys/67a4de72b067ce0008c68c3a
😎 Deploy Preview https://deploy-preview-1723--olmv1.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

@anik120 anik120 changed the title (catalogd) serveFile for all endpoint instead of serveContent 🌱 (catalogd) serveFile for all endpoint instead of serveContent Feb 6, 2025
name: "Server returns 404 when non-existent catalog is queried",
expectedStatusCode: http.StatusNotFound,
expectedContent: "404 Not Found",
expectedContent: "404 page not found",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh this is interesting. I actually don't love this (because we aren't serving pages), but I also think it doesn't actually matter at all. It's just my OCD.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right. I guess it's something we have to live with if we want to serveFile

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is the motivation for using serveFile instead of ServeContent as it is? Is there any specific reason to prefer one over the other?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Might be worth looking at the implementations to see if there really is a significant difference. If it's just a difference of who opens the file, then maybe sticking with ServeContent is better because then 404 errors are consistent.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I took a look. ServeFile has a bunch of handling for directories, and then eventually calls serveContent. I think we close this and keep things as they are?

Sorry for the noise @anik120 I know I was the one that originally suggested this change.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No worries, I'm good with it 👍🏽

@codecov
Copy link

codecov bot commented Feb 6, 2025

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 67.45%. Comparing base (099a6cf) to head (09a0392).
Report is 2 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1723      +/-   ##
==========================================
- Coverage   67.58%   67.45%   -0.14%     
==========================================
  Files          59       59              
  Lines        4982     4977       -5     
==========================================
- Hits         3367     3357      -10     
- Misses       1371     1375       +4     
- Partials      244      245       +1     
Flag Coverage Δ
e2e 53.00% <ø> (-0.09%) ⬇️
unit 54.61% <100.00%> (-0.17%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@anik120 anik120 closed this Feb 6, 2025
w.Header().Add("Content-Type", "application/jsonl")
http.ServeContent(w, r, "", catalogStat.ModTime(), catalogFile)
http.ServeFile(w, r, catalogFilePath(s.catalogDir(catalog)))
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Something I found from internet might be useful for the context

Feature	                     http.ServeFile                     http.ServeContent
Source	                     Directly from disk              Any io.ReadSeeker (e.g., memory, disk, network)
Headers                      Auto-detected                    Manually specified
Performance             Optimized for static files     Flexible but requires more control
Use Case	            Serving files from disk	     Serving custom or in-memory content

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants