Fix or add code block language marking

[rubiesonthesky]

Summary

These correct the code block language markings

Motivation

Supporting details

Related issues

Metadata

• Adds a new document
• Rewrites (or significantly expands) a document
• Fixes a typo, bug, or other error

[github-actions]

Preview URLs

• https://pr19259.content.dev.mdn.mozit.cloud/en-US/docs/Web/HTTP/Authentication
• https://pr19259.content.dev.mdn.mozit.cloud/en-US/docs/Web/HTTP/Basics_of_HTTP/Data_URLs
• https://pr19259.content.dev.mdn.mozit.cloud/en-US/docs/Web/HTTP/CORS
• https://pr19259.content.dev.mdn.mozit.cloud/en-US/docs/Web/HTTP/Configuring_servers_for_Ogg_media
• https://pr19259.content.dev.mdn.mozit.cloud/en-US/docs/Web/HTTP/Cookies

Flaws

Note! 3 documents with no flaws that don't need to be listed. 🎉

URL: /en-US/docs/Web/HTTP/Basics_of_HTTP/Data_URLs
Title: Data URLs
on GitHub
Flaw count: 1

• bad_bcd_links:
  • no explanation!

---

URL: /en-US/docs/Web/HTTP/Configuring_servers_for_Ogg_media
Title: Configuring servers for Ogg media
on GitHub
Flaw count: 1

• broken_links:
  • Is currently http:// but can become https://

External URLs

URL: /en-US/docs/Web/HTTP/Cookies
Title: Using HTTP cookies
on GitHub

No new external URLs

---

URL: /en-US/docs/Web/HTTP/Basics_of_HTTP/Data_URLs
Title: Data URLs
on GitHub

No new external URLs

---

URL: /en-US/docs/Web/HTTP/Authentication
Title: HTTP authentication
on GitHub

No new external URLs

---

URL: /en-US/docs/Web/HTTP/CORS
Title: Cross-Origin Resource Sharing (CORS)
on GitHub

No new external URLs

---

URL: /en-US/docs/Web/HTTP/Configuring_servers_for_Ogg_media
Title: Configuring servers for Ogg media
on GitHub

No new external URLs

(this comment was updated 2022-08-08 22:29:59.674257)

[hamishwillee]

@rubiesonthesky Thanks for this. The http fixes to code blocks are great.
However apache, nginx, powershell are not supported languages - the supported set are here: https://github.com/mdn/yari/blob/main/build/syntax-highlight.js#L15

I've kicked off mdn/mdn-community#170 to discuss what we do in these cases. Normally we just mark them plain if unsupported. However I am leaning towards the idea that it is better to mark them as the type that prism uses even if we don't support it.

Anyway, that won't resolve instantly. Could I suggest you revert to plain for the unsupported cases and we can then get all these http fixes in?

[rubiesonthesky]

@hamishwillee I did what you suggested. It makes sense for me and I was wondering after I submitted this that should I revert some changes.

I wonder would it be technically possible and would it make sense for editors if some blocks could be marked with plain nginx or plain (nginx) to communicate what the actual block should be. That could be searched later if support comes. But maybe that would be just really confusing for editors (humans). And that would not help with editor support, since those are just checking the first parameter.

But this isn't right place to discuss this guideline :D

Code blocks should now be marked with http or plain in this PR.

[hamishwillee]

@rubiesonthesky Thank so much. I'll merge that.

plain (nginx) is an interesting idea - at least it would be more obvious the intent. My worry is that the toolchain might choke on the syntax - for example in linters. You could suggest this in the community discussion.