HISTORY OF PHYSICS
Superconductivity, the electric conduction without energy loss below a critical temperature, was discovered in 1911 by Heike Kamerlingh Onnes, at Leiden.
1/
In Berlin, 1934, Walther Meissner and Robert Ochsenfeld discovered that superconducting materials expel magnetic fields from their interiors.
2/
@VergaraLautaro I'm surprised by the gap between 1911 and 1934.
I would expect the lack of magnetic field inside to be theorized ~immediately (or at least once it was noticed that the zero resistance also applied to AC), given that Lenz's law was formulated in first half of 19th century.
So was it just hard to directly observe the magnetic field around superconductive samples?
@robryk
Both World Wars had an impact on research, also on superconductivity.
Field expulsion does not follow from Lenz’s law, since perfect conductor would produce currents to *maintain* a field that was present already, and for years that’s what experiments seemed to show.
Here’s a book-length history that does a nice job of describing the intellectual history and putting it into social and political context.
https://www.rutgersuniversitypress.org/the-cold-wars/9780813532950
It works for me. Is it 404 for you, or is the website unavailable?
Anyway, the book is "The Cold Wars: A History of Superconductivity" by Jean Matricon and Georges Waysand.
@VergaraLautaro @robryk
Looks like the link from the image is broken, but the link itself works? Is this a Mastadon bug?
(By image you mean preview, right?)
I confirm that this is the case for the post when viewed on fediscience.org, but it does not happen for the post when viewed e.g. on my instance. The broken link is https://www.rutgersuniversitypress.org/book-details/
Each instance generates the preview on its own when it receives a post. I suspect that when fediscience.org did that, the website in question issued a redirect to the broken link for some reason. Let me try to find the raw form of the post to confirm what was actually sent out though.
If you take a look at https://fediscience.org/@jsdodge/109480278297608998.json, you can see that the wrong link is nowhere present. So, it seems that fediscience.org managed to break the preview. Can you try replying with the same link (e.g. in this conversation) to see if that's repeatable?
And now there is no preview. I guess the admins are on it.
I spoke too soon: the preview appeared after a delay, and the link is broken.
Yup. It seems that it's fediscience-specific for some reason. Either a very weird bug, or the target website does the wrong thing when visited by fediscience's link preview generator (maybe if visited by something with a weird user agent? dunno; i'm too lazy at the moment to try figuring out what requests does fediscience's preview generator make).
And I’m too incompetent! 😂
Thanks for the help.
If you're curious, a request for an HTTP{S,} page specifies the part of the URL after the domain and a set of headers[1]. These headers make the request more precise (e.g. "what's the part of URL before the /", "what formats can the client handle" or "what (human) languages the client desires to see", "what cookies does the browser have for this server"), specify housekeeping-style things about the connection (e.g. "can compression be used", "is the client going to send another request on the same connection") and pieces of information that the server can make use of (in particular, User-Agent: "what is the software running in the client" and "what page did the user come from"[2]).
One of the possible responses means "this is a valid URL, but the thing it points to has a different canonical URL: please fetch that one instead (and remember this relationship)". It's called "permanent redirect" or "301".
I suspect that fediscience's previewer is making its request in a way that's different from a browser and e.g. qoto.org's previewer. I suspect that the website reacts to that difference in a silly way, by responding with a redirect to that broken URL.
What can be the difference that matters? The two most obvious ones are User-Agent header and the IP the request is coming from.
I've tried fetching the correct URL with some totally weird User-Agent and nothing weird happened, so it's either not that, or it reacts to a very specific User-Agent in a weird way.
A totally different hypothesis is that the previewer fetches that page using a simulated browser and some JavaScript in that page redirects the simulated browser to the broken URL.... and now I've found the culprit. Let me post about the actual culprit separately.
[1] I'm talking about "GET requests"; you can think of it as "normal" requests to fetch something as opposed to form submission requests.
[2] This used to be sent ~always by browsers in the past, currently the set of situations when it's sent and the precision of the value are greatly diminished. (FTR this header is called Referer, with the spelling mistake in it.)
Yup, repeatable.
@FrankSonntag, could you investigate why, when you look at the previous post at https://fediscience.org/@jsdodge/109485275489976147 the preview links to a different URL than the one mentioned in the post?
@jsdodge @VergaraLautaro @FrankSonntag
It seems that the problem is that the actual page declares that the broken URL is its canonical URL in HTML:
```
$ curl -s https://www.rutgersuniversitypress.org/the-cold-wars/9780813532950/ | grep canonical
<link rel="canonical" href="https://www.rutgersuniversitypress.org/book-details/" />
```
So, you're arguably doing the correct thing and the website is broken.
@robryk @jsdodge @VergaraLautaro thanks for helping with the troubleshooting. Fediscience uses a vanilla Mastodon version and I am not sure why it would behave differently from others sites w/r to the preview generation.
Given the broken canonical link I believe we are indeed doing the right thing - which raises the question why the preview on qoto.org works:)
@FrankSonntag @jsdodge @VergaraLautaro
qoto.org uses Glitch + some other customizations, so I would assume that this changes _something_ in the preview generator.
I've emailed someone from that publisher (they don't have a published webmaster contact) about that issue. I would have ccd you, but couldn't find an email address.
@FrankSonntag @jsdodge @VergaraLautaro
Ah: the preview works _in the logged in view_, but also doesn't on the publicly-available single-thread page. So, there's probably no inter-instance difference here, but only some very weird difference in how Mastodon renders previews in different UIs.
@robryk @jsdodge
Strange.
Now it works.
Previously it appeared "ISBN number not found."
Thanks!