The bug is related to the fact that the parent revision of that deposit is not present in the archive (see https://archive.softwareheritage.org/browse/revision/3d4aadc83990ccda9cc94a554ca69f6dedb1e071/?origin=https://hal.archives-ouvertes.fr/hal-01897934).

Indeed, returning a 404 error seems the best option here. Will fix that asap.

For file paths it would be nice to also support steps that use usual file/dir names foo/bar/baz, as a more readable alternative to number-based steps.

I can confirm, all the 4 work with your commit and xss is too not working.

Antoine, I am really impressed! This already makes a big difference. And there are more than a million notebooks out there on GitHub.

I started working on this by adding client side rendering of notebooks in the archive web application (see D1415).

@kalpitk , I have submitted D1412 fixing the observed issues. What do you think ?

There is a complication when a notebook refers to images via a relative link.
For example, the notebook above (it is a real one) refers to an image with by images/dans.png, but when I am in NBviewer looking at the SHA copy of it, that gets translated to the url

Closing this as from my point of view, the browse/content/raw endpoint should only have text/plain or application/octet-stream content type.

Closed by rDWAPPS3f8b34cef98ca54e46e4e558954f09fd89ef8492.

is this completed ?

That is by design (although, admittedly, not really nice). More than "fixing" this specific issue, we might consider revamping/uniforming the general way of presenting sub-sites. But that is not gonna be just a fire-and-forget logo fix.

On it. :)

In T1615#29950, @zack wrote:

To clarify: "assignment" of tasks to specific people is something only us, Software Heritage maintainers, do. Hence I'm de-assigning the issue from @01shobitha.

Second, there is no need to ask permission to contribute patches, nor there is a notion of open issues being "reserved" to anyone in particular. Hence, @Augustinetharakan12, feel free to work on a patch for this if you are motivated to do so.

Submitted patches (as code reviews requests in Phabricator) will be judged on their merits, no matter who submitted them. First come, first served.

Cool ... Thank you :) @zack

Continued in D1290

@kalpitk , as you opened D1290, you should abandon this diff to avoid duplicate.

I pushed changes through arc : D1290
Probably the problem was line 34, which had more than 79 characters. This was preventing me to stage changes.

@ardumont Changed the title.

Fyi, patch is fine locally.

Build has FAILED

Build has FAILED

Build has FAILED

Build has FAILED

Also, please adapt appropriate the commit message.

Redirecting to the lowercase sha1 endpoints when such cases are encountered seems the right way to implement this.

Build has FAILED