Comments (25)
Would providing a json format (issue 27) have less security concerns? Chrome
team has tools which need to get current state of certain files. This is
currently done via chromium svn servers but I'd like to transition these tools
to use GoB. An example file which tools fetch is:
https://chromium.googlesource.com/chromium/src/+/master/DEPS
Original comment by [email protected]
on 6 May 2013 at 1:10
from gitiles.
Would it be sufficient to always set the content-type to something like
"application/octet-stream"? Are there any browsers that would attempt to
parse/display that, rather than just downloading? That might help avoid the
browser hijacking issue, while still allowing easy programmatic access from our
tools.
Original comment by [email protected]
on 6 May 2013 at 4:14
from gitiles.
Or another option, maybe always put the file(s) into a zip archive, which would
force downloading and unzipping, again avoiding browser handling of the
content, but still being pretty easy for scripts to deal with.
Original comment by [email protected]
on 6 May 2013 at 4:18
from gitiles.
#1: JSON is a good idea, that would be easy to implement in the short term.
Works for the scripting case but we still want true raw file support for e.g.
viewing in-repo HTML.
#2: Unfortunately if you include a file with an <img> or <script> tag browsers
are still liable to do content sniffing regardless of Content-Type in the
header :(. Modern browsers will respect Content-Disposition: Attachment but
older IEs may not. And again we still want to support browsing raw HTML stored
in the repo.
#3: Zip archive is another idea, but between that and JSON I think I prefer
JSON :)
Original comment by [email protected]
on 6 May 2013 at 9:30
from gitiles.
Also an issue for Google's "Skia" open-source project. Details are at
https://code.google.com/p/skia/issues/detail?id=1898 ('git transition blocker:
skia_tools.js needs to download tip-of-tree global_variables.json')
Original comment by [email protected]
on 13 Dec 2013 at 8:43
from gitiles.
GitHub has this functionality (they serve raw blobs as text/plain). Are they
just unaware or unconcerned about the content-sniffing issue alluded to in #2?
Original comment by [email protected]
on 8 Jan 2014 at 1:41
from gitiles.
github solves the problem of cookies by serving the raw URL from a different
hostname; i.e. https://github.com/dataarts/tailbone/blob/master/Guardfile is
served raw from https://raw.github.com/dataarts/tailbone/master/Guardfile
Could that work for gitiles?
Original comment by [email protected]
on 6 Feb 2014 at 11:42
from gitiles.
Yes, for googlesource.com we plan to use a new, cookieless domain (and for
open-source Gitiles the domain will simply be configurable and we trust
administrators to understand the risks and implement their own cookie policy).
This quarter I plan to do JSON support and at least get the ball rolling with
our security/domain teams on the cookieless domain part.
Original comment by [email protected]
on 6 Feb 2014 at 11:47
from gitiles.
Blocking:
https://code.google.com/p/chromium/issues/detail?id=337030
https://code.google.com/p/chromium/issues/detail?id=345087
and some aspects of:
https://code.google.com/p/chromium/issues/detail?id=343251
Original comment by [email protected]
on 10 Mar 2014 at 4:44
from gitiles.
Base64-encoded raw file support is checked in as:
https://gerrit-review.googlesource.com/55202
Example URL (won't work until this is released for googlesource.com):
https://gerrit.googlesource.com/gitiles/+/master/gitiles-servlet/src/main/java/c
om/google/gitiles/PathServlet.java?format=TEXT
Original comment by [email protected]
on 15 Mar 2014 at 4:28
from gitiles.
Original comment by [email protected]
on 24 Apr 2014 at 11:33
from gitiles.
Original comment by [email protected]
on 25 Apr 2014 at 4:17
from gitiles.
FWIW, the base64-encoded delivery is fine for my Chromium use cases. If you
want to leave this open pending "true" raw file support, that's fine, but I
don't think it should be a priority.
Original comment by [email protected]
on 25 Apr 2014 at 4:22
from gitiles.
From the Skia perspective, base64 and JSON cover all of our bases too.
Original comment by [email protected]
on 25 Apr 2014 at 4:49
from gitiles.
Blocking crbug.com/369329
Original comment by [email protected]
on 15 May 2014 at 7:10
from gitiles.
sebmarchand, that crbug appears to be about a Python script. Any reason base64
doesn't work for you?
Original comment by [email protected]
on 15 May 2014 at 7:22
from gitiles.
Yeah, I updated that bug with some notes on how to fetch. I don't think this is
blocking.
Original comment by [email protected]
on 15 May 2014 at 7:37
from gitiles.
Another issue is with pointing bug reporters and others to download
bisect-builds.py from the Chromium repo. We used to link to the file on
src.chromium.org. This page seems to now point to the gitiles page:
http://www.chromium.org/developers/bisect-builds-py
But that's not especially useful as there's no clear way to download it. For
this use, I think we'd have to be able to download the file itself, and not
some encoded version.
Original comment by [email protected]
on 4 Sep 2014 at 2:55
from gitiles.
I was able to download bisect-builds.py by adding ?format=TEXT on the end, then
manually base64 decoding it, but it was a bit of a pain...
Original comment by [email protected]
on 15 Sep 2014 at 1:35
from gitiles.
So does that mean this isn't going to be fixed?
base64 decoding is not a solution.
A normal person should be able to go to
https://chromium.googlesource.com/chromium/src/+/master/tools/bisect-builds.py
And simply click a link to download the file.
Original comment by [email protected]
on 10 Oct 2014 at 12:38
from gitiles.
This is a real PITA!! Why on earth google doesn't provide a "raw" code link??
Absolutely absurd. Please fix!
Original comment by [email protected]
on 19 Oct 2014 at 2:11
from gitiles.
please increase the priority of this - it's a real pain to have to attach
bisect-builds.py to tickets when I want people to help me bisect Chromium.
Asking them to base64 decode a raw download is too much of a barrier to entry.
Original comment by [email protected]
on 30 Jan 2015 at 9:53
from gitiles.
wfh, the way to bump priority is to raise this with your local chrome-infra
team member and they can work it into feature planning with our team.
As for bisect-builds.py, I'm not yet convinced base64 decoding is too much of a
barrier to entry.
The documentation page linked above says, paraphrasing:
1. Download bisect-builds.py from this link.
2. Run this python command.
Would the barrier to entry really be that much higher if the documentation were
rewritten to say:
1. Run this command to download bisect-builds.py:
$ curl
'https://chromium.googlesource.com/chromium/src/+/master/tools/bisect-builds.py'
| base64 -d > bisect-builds.py
2. Run this python command
?
Original comment by [email protected]
on 30 Jan 2015 at 10:00
from gitiles.
d:\src>curl
'curl' is not recognized as an internal or external command,
operable program or batch file.
d:\src>base64
'base64' is not recognized as an internal or external command,
operable program or batch file.
So I think it does for some less technical users (that would be typical of
bisect-builds users -- if they were devs they'd already have the tree pulled
and just use it from there.)
Original comment by [email protected]
on 30 Jan 2015 at 10:08
from gitiles.
Ah. Windows. Point taken.
Original comment by [email protected]
on 30 Jan 2015 at 10:19
from gitiles.
Related Issues (20)
- Documentation (even cursory/automatic) of the REST api would be awesome HOT 4
- format=TEXT for +diff handler HOT 9
- Log view is slow HOT 7
- File view is slow (slower than same file's blame view) HOT 6
- add golang meta import tag HOT 1
- Feature request: make json format of revisions range log in googlesource also return changed files HOT 1
- Feature request: show all refs from which a commit is reachable on /+/<hash> pages
- log graph view
- pretty=fuller view broken in some places HOT 1
- Render markdown (README.md) HOT 4
- [blame] links should show blame for parent of the commit.
- Add option for embedded (iframe) Gitiles views. HOT 1
- File diff link in fuller log view incorrect HOT 2
- Can't ctrl-f search for line numbers in file view
- follow file history across renames/etc...
- [deleted issue]
- [deleted issue]
- [deleted issue]
- copy of source code snippet drops blank lines
- Markdown multilevel lists aren't recognized correctly
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from gitiles.